Design of A Data Logger

COURSE: Electronic Design 3
REPORT ON: Design of a Data Logger (Phase 3 Report)
REPORT BY: Group 6 (Corresponding Author: Muhammad Simjee - simjeem@gmail.com)
Irisa Govender 203502431
Mark Joseph 203504473
Nicol Naidoo 203503153
Seeralin Nayager 203505544
Muhammad Simjee 203503366
Shivan Singh 202511992

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. The device allows the user to download the stored data to a PC via the USB port. 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.
ii
Contents
Abstract ................................................................................................................................................... ii
Contents.................................................................................................................................................. iii
List of Abbreviations............................................................................................................................... v
1 Introduction ..................................................................................................................................... 1
1.1 Overview................................................................................................................................ 2
1.2 Physical Implementation........................................................................................................ 4
1.3 Proposed Operation................................................................................................................ 5
2 Implementation................................................................................................................................ 5
2.1 Measurement Module ............................................................................................................ 5
2.1.1 Measurement Unit ............................................................................................................. 5
2.1.1.1 Temperature and Humidity Measurement ................................................................ 5
2.1.1.2 Time Stamping.......................................................................................................... 9
2.1.1.3 Control .................................................................................................................... 15
2.1.2 Memory Unit ................................................................................................................... 15
2.1.2.1 Sampling Rate......................................................................................................... 16
2.1.2.2 Data Storage............................................................................................................ 16
2.1.2.3 Measurement Data .................................................................................................. 16
2.1.2.4 Time Stamped Data................................................................................................. 17
2.1.2.5 Physical Implementation......................................................................................... 17
2.1.2.6 Power Consumption................................................................................................ 18
2.1.2.7 Writing to EEPROM............................................................................................... 18
2.1.2.8 Development and Testing of EEPROM Software .................................................. 20
2.1.3 System Operation ............................................................................................................ 22
2.1.3.1 Tasks Required ....................................................................................................... 22
2.1.3.2 Sampling and Storage of Base Time Stamp............................................................ 22
2.1.4 Complete Circuit Diagram............................................................................................... 26
2.1.5 Construction of Measurement Module ............................................................................ 28

iii
2.2 PC Interface Module ............................................................................................................ 29
2.2.1 Hardware Requirements .................................................................................................. 29
2.2.2 The Download Procedure ................................................................................................ 30
2.2.2.1 Communication Protocol ........................................................................................ 31
2.2.2.2 USART Communication......................................................................................... 32
2.2.2.3 EEPROM read process ........................................................................................... 33
2.2.2.4 Actual download procedure .................................................................................... 35
2.2.2.5 The Visual Basic Graphical User Interface............................................................. 39
2.2.2.6 Data manipulation using PC software..................................................................... 40
3 Housing ......................................................................................................................................... 43
3.1 The Measurement Unit ........................................................................................................ 43
3.2 The Memory Unit ................................................................................................................ 43
3.3 The PC Interface Unit .......................................................................................................... 44
4 Module Tests ................................................................................................................................. 45
5 Analysis of Design ........................................................................................................................ 46
5.1 The Measurement Module ................................................................................................... 46
5.2 The PC Interface Module..................................................................................................... 46
5.3 Housing................................................................................................................................ 46
6 Costing .......................................................................................................................................... 48
7 Conclusion..................................................................................................................................... 49
References ............................................................................................................................................. 50
Contacts................................................................................................................................................. 53
Appendix A ........................................................................................................................................... 54
Average Sensor Supply Current Calculation......................................................................................... 54
Power Calculation for EEPROM .......................................................................................................... 55
Power Comparison between Microcontroller Based RTC and Dedicated RTC.................................... 55
Power Calculation for Microcontroller ................................................................................................. 57
iv
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
v
1 Introduction
The conservation of wildlife is becoming a major concern of modern society. As humans encroach on
the habitats of animals, the animals are displaced and as such there are a growing number of animals
making their way onto the endangered species list. Many different species of bats are also becoming
part of this harmful trend. A myriad of conservation groups exists with a goal of being able to save
these amazing creatures. However, in order to successfully achieve this goal, research into the
optimum living conditions of bats must be investigated if sanctuaries and homes for these creatures are
to be constructed.
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.
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 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.
Table 1: Overall System Tasks and Constraints
1
1.1 Overview
Using the tasks illustrated in Table 1 a system block diagram was created.
Figure 1: Overall System Block Diagram
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)1 and the other being the downloading of data to
the PC and the processing of data (PC Interface Module)2. These tasks are made visible on the
following block diagram.
1
For reasons of simplicity the functional unit performing the task of measurement and data storage will be
known as the measurement module
2
For reasons of simplicity the functional unit performing the tasks of data download and data processing will be
known as the PC Interface module
2
Figure 2: Block Diagram of System Modules
The implementation of these two functions could be achieved in a single physical device. Such an
implementation would be cost effective as manufacturing, housing and materials costs would be
reduced. However, since both functions can be done independently, physically separating the
functions provides advantages that are undoubtedly superior. These benefits are now discussed with
reference to the following diagrams.
Table 2: Tasks and Constraints of the Measurement Module
Table 3: Tasks and Constraints of the PC Interface
3
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.
1.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.
Figure 3: Block Diagram of System Modules Including Memory and PC Interface Unit
4
1.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
emphasised enough.
2 Implementation
2.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.
2.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.
2.1.1.1 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 vapour pressure has a
corresponding change, consequently there is a change in RH. This change is due to a directly
proportional relationship between saturation vapour 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 Sensirion SHT71 offers the closeness of
sensors that is 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 (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
5
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.
2.1.1.1.1 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.
The sensor requires no other peripheral hardware except for a source,

decoupling and connection to the microcontroller.
2.1.1.1.2 Communicating with the Sensor
2.1.1.1.2.1 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.
2.1.1.1.2.2 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.
Figure 4: Communication Sequence

6
Figure 5: Timing Diagram for a Transmission Start Sequence
2.1.1.1.2.3 Transmitting a Command

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.
Figure 6: Timing Diagrams for the Temperature Command
2.1.1.1.2.4 Measurement Process

Once the microcontroller issues the command for the sensor to measure RH it then has to wait whilst
the 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
send 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 signal
is 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.
7
Figure 7: Timing Diagram for Data Received
2.1.1.1.3 Implementation of Sensor Communication

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 endeavouring 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.
2.1.1.1.4 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
8
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) .
2.1.1.2 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.
2.1.1.2.1.1 . 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.
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.
2.1.1.2.2 . 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.
2.1.1.2.3 . Other Methods of Implementing a Real Time Clock

Another method of implementing a real time clock is through the use of the microcontroller’s internal
9
timer. Once an initial time stamp from an external real time clock comes in, the microcontroller takes
control of time-keeping.
Many microcontrollers have a 16 bit timer that can be used to implement the microcontroller based
real time clock. Using the microcontroller at a clock frequency of 4 MHz, and with the maximum
prescaler value of 1024, the period between timer overflows is:
−1
 4 Mhz 
period =   = 0.256 × 10 −3 sec
 1024 
Using the 16 bit timer implies that a maximum count of 216 × 0.256 × 10 −3 sec = 16.777 sec . This
maximum count makes it possible to generate a timer interrupt every 15 seconds. To count to 15
seconds, the value that needs to be loaded into the timer’s register is:
(16.777 − 15) ÷ (0.256 × 10 −3 ) = 4369

Using another register as a counter allows for the control of the data logging period.
The most important factor in the choice between the different methods is the power consumed by
each. Power estimates have been performed for the different method and a comparison based on the
estimates yields the dedicated real time clock as a more power efficient option.
2.1.1.2.4 Power Comparison between Methods3

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.
2.1.1.2.5 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 coin 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 I average = 0.3µA . Ignoring the non-linear voltage-capacity
behaviour of the battery, the expected service life of the battery can be calculated by:
3
Current consumption based on the ATmega16L
10
Capacity
t service = .
I average
90mAh
t service = = 300 × 10 3 hrs
0.3µA
The above figure translates into 34 years; however, the non-linear behaviour 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.
40 1
39 2
38 3
37 4
36 5 SS Vcc1 Vcc2
16 1
MOSI
35 6 Vbat
15 2
34 7 MISO
SCK VccIF 14 3
33 8 Crystal
SDO
32 9 13 4
GND
31 10 SDI 12 RTC 5
ATmega16L INTO
3V battery
30 11 SCLK
11 6
29 12 CE 10 7
28 13 SERMODE GND
9 8
27 14
26 15
INT0
25 16
24 17
23 18
22 19
21 20
Figure 8: Schematic diagram of the real time clock.
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.
2.1.1.2.6 . 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.
11
Master Initialistaion Slave Initialistaion
SS, MOSI, SCK => o/p

SS, MOSI, SCK => i/p pins
pins MOSI => o/p pin
MISO => i/p pin
Set bits SPE and MSTR of Set bit SPE of SPCR

SPCR register. register.
Clear SPI interrupt flag by Clear SPI interrupt flag by

reading SPSR and SPDR. reading SPSR and SPDR.
SPDR = main_data
Wait for SPI interrupt
No
flag
Yes
Wait for SPI interrupt End process

No
flag
Yes
Clear SPI interrupt flag by

reading SPSR and SPDR.
SPDR = arb_data

No flag
Yes
Ouput main_data
to LED’s
End process
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 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
Figure 10.
Figure 10: Data transfer between the master and slave.
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.
12
2.1.1.2.7 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 initialise
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 initialisation process of the real time clock is shown in Figure 10.
RTC_Initialisation Transmit_data
SS, MOSI, SCK => o/p

pins Clear SPI interrupt flag by
MISO => i/p pin reading SPSR and SPDR.
Set bits SPE and MSTR of

SPCR register. SPDR = data

Enable SPI on RTC No flag
Yes
Call Transmit_data
Return
Call Transmit_data
Disable SPI on RTC
All time info sent?

No
Yes
End process
Figure 11: RTC initialisation process.
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 initialisation process includes writing to the RTC control register to enable the alarm function and
start the clock by enabling the oscillator.
13
Figure 12: Timing Diagram for SPI single Byte Write.
2.1.1.2.8 Real-Time Clock Alarm function 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-
up from the port pin on the microcontroller. During each interrupt routine, the ‘low’ I NT 0 signal is
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 time
stamp is requested by the microcontroller.
Figure 13: Real Time Clock Read Procedure.

14
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.
The timing diagram for the SPI single byte read process is illustrated in Figure 14 below.
Figure 14: Timing Diagram for SPI Single Byte Read.
2.1.1.3 Control
2.1.1.3.1 Product Selection

A microcontroller carries out all its tasks concerned with the system control. The ATmega16L
produced 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 ATmega16L 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 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 both
ATmega16L 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.
2.1.1.3.2 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.
2.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.
15
Table 4: Tasks and Constraints Affecting Memory Module
2.1.2.1 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. These calculations are illustrated in the power
budget section 2.1.4.1.1.
2.1.2.2 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 minimise 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.
2.1.2.3 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.
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
16
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.
2.1.2.4 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 synchronisation 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.
2.1.2.5 Physical Implementation
2.1.2.5.1 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 for 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.
2.1.2.5.2 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.
17
Figure 15: MMC Emulation Using EEPROM
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.
Figure 16: The Physical Interface between the Microcontroller and EEPROM
2.1.2.6 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.
2.1.2.7 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.
18
The Write Protect (WP) pin on the EEPROM was grounded to enable writes to the EEPROM. To
write a data set to EEPROM, the master had to send at least four bytes following a start condition– one
byte for the slave address and the write command, one byte each for the upper and lower data
addresses, and then the data byte. After each byte was sent, the EEPROM would respond with an
acknowledge bit. The acknowledgement occurred in the ninth clock cycle and allowed for testing
during the software development process, as well as error handling in the final program.
Writing to EEPROM involved the development of a procedure, EWrite, which incorporated two sub-
procedures and a function. An array passes the data to be stored to EEPROM to the EWrite procedure.
Figure 17 illustrates TWI_Initialisation, the sub-procedure to initialise the TWI communication

between the microcontroller and the EEPROM. TWI_Initialisation sets up the speed of the TWI clock,
as well as the microcontroller’s master address. Once the start condition is sent, the TWI is initialised
and is ready to transfer data.
Start
Setup Bit Rate Register
Setup Master Address
Send Start Condition
End
Figure 17: Flow Diagram of TWI_Initialisation
Figure 18 illustrates the function, TWI_Stat, used to monitor the status of transmission. The sub-
procedure waits until the TWINT flag in the control register is set, indicating the end of a nine-bit
transmission. The value stored in the Two Wire Status Register (TWSR) indicates whether a
transmission has been successful. After each call of the TWI_Stat function, the TWI_Stat passes the
TWSR value back to EWrite for comparison. If the comparison indicates that the transmission has
been unsuccessful, the that particular data transmission is repeated.
19
TWI_Stat
Start
Read in TWI Control

Register
Start Clear lower 7 bits of

TWCR
Call
TWI_Initialisation TWINT flag NO
set?
Call TWI_Stat
YES
1
Start Condition NO Read in TWI Status
sent? Register
YES
Mask Lower 3 Bits of
TWSR
Send Slave Address
and Write Command
Pass masked version of
TWSR back to EWrite
Call TWI_Stat
Start
Slave Address 2 NO
sent?
YES
Figure 18: Flow Diagram of TWI_Stat
Send Higher Byte of
Data Address TWI_Initialisation and TWI_Stat make up the bulk of the procedure
EWrite, which is utilised to write to EEPROM. EWrite obtains the
Call TWI_Stat addresses to write to, as well as the data to be written, from the main
program. The diagram beside is the flow diagram illustrating the operation
of the EWrite procedure. Once EWrite is called, the start condition is sent
3
High Byte of Data NO through the Two Wire Interface. The EEPROM’s slave address is loaded
Address sent?
and sent. EWrite comprises a number of loops where TWI_Stat is called.
YES These loops allowed for testing of the software during the development
phase. The following section describes the development and testing of the
Send Lower Byte of software to write to EEPROM.
Data Address
Call TWI_Stat 2.1.2.8 Development and Testing of EEPROM Software

For the development process, the EEPROM was connected in a similar
4 manner to that described in Figure 16, but with the EEPROM on a
Low Byte of Data NO
Address sent? breadboard and the microcontroller on an STK500 programming board.
After each call of TWI_Stat, the microcontroller performs a comparison
between the value in the TWSR and the transmission code. It was
YES therefore possible to test the operation of the code by lighting up the Light
Send Data Emitting Diodes (LEDs) on the STK500 board when the value in TWSR
did not match the expected value. The sequence of LEDs light up was
Call TWI_Stat chosen to represent the value of the loop position (indicated beside the
decision boxes in the diagram beside).
5 NO
Acknowledge When an error occurred, the number of the last correctly executed loop
Received
was determined from the LEDs on the STK board. The EWrite code was
YES then re-examined and edited to output the value of TWSR in order to
YES
20
More Data to Send
NO
Send Stop
Condition
END
determine the cause of the error. Errors encountered included the receipt of a “not acknowledged”
(NACK) bit or the occurrence of an undefined TWI operation.
The reception of the NACK bit occurred because of the incorrect sequence of events being followed.
To correct the error, the function TWI_Stat was created using the correct sequence of events.
2.1.2.8.1 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 6 bits of data in the 4th 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 19: 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.
21
0x00
Number of Samples
-------n-------
0x01 Taken (2 bytes)
Hour 0x02
------------------- Time Stamp Data
Date
------------------- (4 Bytes)
Month
-------------------
Year 0x06
Measured 0x07
n1 → n2 (Temperature
and Humidity Data)
Data 0x09
Measured 0x0A
and Humidity Data)
Data 0x0C
Measured 0x0D
and Humidity Data)
Data
0x0F
0x10
Measured n7 → n8 (Temperature
and Humidity Data)
Data 0x12
0x13 Time Stamp
Hour Synchronisation
0x14
0x1BE0
Measured n4391 → n4392
(Temperature and
Data Humidity Data)
0x1BE2
Reserved
0x2000
Figure 20: Memory Map of the AT24C64A Serial EEPROM
2.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.
2.1.3.1 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
• Manipulation of Temperature and Humidity Data
• Storing of Temperature and Humidity Data
• Sample Counter
2.1.3.2 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, 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.
22
2.1.3.2.1 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.
2.1.3.2.2 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.
2.1.3.2.3 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.
2.1.3.2.4 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.
2.1.3.2.5 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:
• Initialisation
• Active Mode
• Power Down Mode
In order to use the microcontroller in a power down mode an entirely interrupt driven system is
23
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.
Start
Initialization
Power Down If Interrupt Occurs Active Mode

(Interrupt Service
Mode Routine)
Figure 21: 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 22. 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 8
hours. Once all processes are completed the system will also return to power down mode.
24
Figure 22: Hourly Interrupt Routine
25
4
2.1.4 Complete Circuit Diagram

Using the requirements of the individual components the complete circuit diagram of the measurement
module was created.
VCC
DATA
4 1 SCK
GND
SHT71 VDD
3 2
40 1
39 2
38 3
Vcc1 Vcc2
37 4 16 1
36 5 SS Vbat
15 2
MOSI
35 6 VccIF 14 3
34 7 MISO
SCK SDO
33 8 13 4
SDI 12 RTC Crystal
32 9 RESET 5
GND VCC SCLK INTO
31 10 11 6
ATmega16L 3V battery
30 11 GND CE 10 7
29 12 XTAL2 SERMODE GND
9 8
28 13 XTAL1
27 14
26 15
PC3 25 INT0
16
PC2 24 17
SDA 23 18
SCL
22 19
21 20
Vcc A0
8 1
WP A1
7 2
SCL AT24C64A A2
6 3
SDA GND
5 4
Figure 23: Complete Circuit Diagram of Measurement Module
4
The notation N_Sample refers to an internal counter which tracks the total number of samples which
have been taken.
26
2.1.4.1.1 Power Budget
It was decided that in order to supply the Measurement Unit with power ordinary alkaline cells would
be used. These cells are relatively inexpensive, convenient in size and readily available. Rechargeable
cells were not implemented as simplicity, with regards to use and maintenance of the product, was of
paramount importance. Rechargeable cells also have a lower shelf life than alkaline cells and they lose
up to 4% of their charge per day. In addition to this rechargeable cells, initially, cost far more than
ordinary alkaline cells.
In order to calculate the size of the battery needed, to meet the 6 month lifespan requirement of the
Measurement Unit, the cumulative average supply currents from all the devices within the
Measurement Unit was included in the calculation. The RTC average supply current was omitted from
this calculation as it does not use the main power supply but rather its own battery source. The
individual average supply current requirements for the sensor, EEPROM, microcontroller as well as
the RTC may be found in Appendix A.
I TOTAL = I AVG _ SHT + I AVG _ EEP + I AVG _ MICRO
= 1.015 ×10 −6 + 2.83 ×10 −6 + 180.26 ×10 −6
= 184.10 × 10 −6 A
Number of hours the battery must source current for = 183days × 24hrs
= 4.392 × 10 3 hrs
Hence the rating of the battery should be = I TOTAL × hrs
= (184.10 ×10 −6 )(4.392 ×10 3 ) = 808.59mA.hrs
Based on the above calculation it was decided that Energizer AA batteries would be used for the
Measurement Unit. These batteries are rated at 2750mA.hrs. Using the configuration of cells shown in
Figure 24 it can be seen that the effective rating of this battery will be doubled to 5500mA.hrs.
Figure 24: Battery Configuration to be used
Using this result the lifespan of the battery is calculated below.
rating
Lifespan (hours) =
I TOTAL
5500 ×10 −3
=
184.1×10 −6
27
= 29.88 ×10 3 hrs
This is equivalent to the battery being able to last for approximately 3.35 years, which is well in excess
of the required lifespan of 6 months.
The reason that such a large margin is included is to attempt to guarantee the user an operation
window of 6 months. Further, in theoretical calculation factors such as impulse currents could not be
taken into account as such data is not provided by manufacturers. However, it must be noted that all
batteries have temperature limitations. The theoretical calculations are only valid for temperatures in
the range of 0°C to 55°C. The lifespan of the battery is significantly reduced when temperatures
exceed its operating range and is completely destroyed at temperatures in excess of 60°C and below
0°C. Thus temperature limitations of the battery limit the overall performance of the system thereby
limiting the overall operating range o f the data logging system.
2.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. The
testing of the final product is discussed in the testing and results section 4.
28
2.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.
2.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 bridge between the Memory Unit and a PC. The Memory Unit is connected using the
standard two-wire interface as discussed in section 2.1.2.7. 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 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 25 illustrates the hardware configuration of the PC Interface Unit and Memory Unit.
29
VCC
47nH
4.7uF 100nF
40 1
TXD
39 2 1 28
2 27
38 3 TEST
3 26
37 4 VCCIO
4 25
AGND
36 5 RXD
5 24
CBUSO
35 6 6 23
GND
34 7 7 FT232RL 22
GND
8 21
33 8 VCC
AREF RESET 9 20 4k7
32 9 RESET
GND VCC
10 19
31 10 11 18 GND
AVCC ATmega16L 3V3OUT
30 11 12 17
USBDM
29 12 13 16
USBDP
28 13 14 15
RXD
27 14
TXD
26 15
PC3
25 16
PC2
24 17 100nF
SDA
23 18
SCL
22 19
21 20
Vcc A0
8 1 FERRITE
BEAD
WP A1
7 2
SCL
AT24C64A A2
6 3
SDA GND
5 4 TO USB PORT
100nF 4.7uF
10nF
Figure 25: 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.
2.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
30
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
2.2.2.1 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 parity 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:
• 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.
n
Number of Samples
n
hours
date
Base Time Stamp
month
year
Figure 26: 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.
•
Figure 27: Measurement Data Block
31
2.2.2.1.1 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.
Initialization Data Block

(6 Bytes)
Measurement Data
Block (13 bytes)
Checksum
Checksum
Figure 28: Data Blocks with Checksum
2.2.2.1.2 Handshaking
Handshaking is employed in order to ensure that the receiver and transmitter are synchronised. 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 checksum value received.
2.2.2.2 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.
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.
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.
32
Figure 29: A Basic Serial Communication Sequence
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.
2.2.2.3 EEPROM read process

Reading from EEPROM involved a similar process to that of writing to EEPROM, which was
discussed in section 2.1.2.7. For the read process, however, the procedure ERead is required to pass
the data from the EEPROM to the microcontroller.
The ERead process calls both the sub-procedure TWI_Initialisation and the function TWI_Stat used in
the EWrite procedure. TWI_Initialisation and TWI_Stat were discussed in section 2.1.2.7.
To read from EEPROM, the master is required to initiate a “mock write” to the EEPROM in order to
read from a specific address. Figure 30 shows the process followed for the mock write.
33
Figure 30: Flow Diagram Illustrating a Mock Write
After the master sends the repeated start condition, the master can then read the data from the
EEPROM. The sequences of events to be followed include resending the device address and then
reading the data from the EEPROM. Multiple bytes can be read from EEPROM, provided the
microcontroller responds an acknowledge (ACK) bit in the ninth clock cycle. The microcontroller
sends the ACK for every data byte to be read beside the final byte. Figure 31 shows the flow diagram
for the ERead process.
34
Start
Resend Device
Address
Call TWI_Stat
NO
Address Sent?
YES
Wait
NO
TWINT Flag Set?
YES
Read in Data
Send
Acknowledgement Bit
Pass Data to Main
YES More Data to

Read?
NO
No
Acknowledgement
Send Stop
Condition
End
Figure 31: The ERead Procedure
2.2.2.3.1 Development and Testing of Software

The development and testing of the ERead procedure followed a similar method to that of the EWrite
procedure mentioned in section 2.1.2.8 . Once the ERead procedure operated without errors, the
EWrite and Eread procedures were executed sequentially, with known data written to certain addresses
in EEPROM. The data was then read from the EEPROM, displayed on the LEDs of the STK500, and
compared with the known data. Once both procedures were fully operational, without any errors, they
were incorporated into the programs for their respective modules.
2.2.2.4 Actual download procedure

The sequence of events involved in the download procedure is as follows:
35
Microcontroller PC
User invokes start

condition by clicking
start “Download”
Microcontroller waits
for start condition
Initialization Block(+
Checksum)
Data
Transmitted Checksum is verified
and Acknowledge
Transmitted
ACK
for Acknowledge
Measaurement Block(+
Checksum) Data
and Acknowledge
ACK Transmitted
for Acknowledge
Measaurement Block(+
Checksum) Data
and Acknowledge
Transmitted
Figure 32: The data download procedure.
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 an interrupt would occur. This interrupt
prompts the microcontroller to resend the previous block of data. This process is highlighted in the
following flow chart.
36
Figure 33: Process describing block data transfer.
The diagram below indicates the entire microcontroller operation in the PC Interface Module.
Wait for Start
Start Condition
Recieved
No
Yes
Read address 0x00 – 0x05
of EEPROM
(Initialization Data)
Compute Checksum
Transmit Function
n=6
Read address n – (n + 8)
of EEPROM
(Measurement Data)
Compute Checksum
Transmit Function
n=n+8
Figure 34: Microcontroller operation in the PC Interface Module
The PC works in conjunction with the microcontroller to download data via the developed
communication protocol. The user initializes the download procedure by clicking on the “Download”
37
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.
Click Download
“Start” condition sent

to microcontroller
Data packet received

by PC with Checksum
PC processes Data
PC Recalculates
Checksum
PC_Checksum = False Discard packet

Received_Checksum?
True
Transmit ACK to
Microcontroller
Wait
Figure 35: Download process between PC and microcontroller.
38
2.2.2.5 The Visual Basic Graphical User Interface
The main objective of the computer-based user interface is to allow the client to easily retrieve and
analyze the downloaded data. It was also imperative that the interface be created in a manner that
provides a user friendly application. To this end, a Visual Basic application was created. This interface
allows the user to download and save data to a specified directory with any desired file name (valid in
Windows). The file is saved as an ordinary text file (.txt). By saving the data in this format, the user is
allowed to further process and view the data using any program or tool that the client is more
acquainted with. A help file developed for this software will be provided as an online guide to the user
for downloading and viewing the data.
The application may be accessed by simply double clicking on the execution (exe) file. Immediately, a
splash screen is displayed to the user while the form loads in the background.
Figure 36: User Interface Start-up Screen
The actual GUI then pops up onto the screen. The user is prompted to enter in a file name to which the
data will be uploaded to. The user may also select the path and directory of this file.
Figure 37: Graphical User Interface
39
Upon clicking the “Download” button, the download process (discussed in Section 2.2.2.4)
commences. When this procedure is finished, a message is displayed informing the user that the
download is complete. If at any stage the user requires assistance with respect to the application or to
the project as a whole; user manuals as well as the three reports written by the group are provided.
These are accessed by clicking on the “Help” drop-down menu. All of these attributes build towards
the application being as user-friendly as possible.
Figure 38: Figure Illustrating Access to the User Manual
2.2.2.6 Data manipulation using PC software

Since the data packets received are raw, a certain amount of data processing was required on the PC
side through the VB application.
The first packet that is received contains six bytes. The first two bytes hold the number of samples
taken; and the remaining four bytes are 8-bit BCD values which contain the initial time stamp (as
illustrated in Figure 39).
Figure 39: Format of initial data packet.
The time stamp data (bytes 3 to 6) need to be converted from their BCD values to decimal values. This
process is illustrated in Figure 40
The actual BCD value that is read is converted to its binary equivalent. This is done by referencing the
user-defined function “DecimalToBinary”. The function also ensures that the binary value returned is
an 8-bit value. This 8-bit value is then separated into a lower and upper nibble. The 4-bit upper nibble
is then sent to another user-defined function (“BinaryToDecimal”) to convert it into decimal. This
value is then multiplied by 10. The lower nibble is also converted to its decimal equivalent. Then, by
simply adding both of these decimal values, the result yields the decimal equivalent of the original
40
BCD value.
Read
BCD Value
Convert to 8-bit Binary
b8 b7 b6 b5 b4 b3 b2 b1
Separate Upper and

Lower nibbles
b8 b7 b6 b5 b4 b3 b2 b1
Convert to Decimal
Convert to Decimal
And Multiply by 10
Add Upper & Lower

Values
Figure 40: Process of converting BCD to binary.
The data packets that follow contain 13 bytes. The first 12 bytes hold the encoded temperature and
humidity values. These values were stored over an 8 hour period. The 12 bytes within the received
packet can be viewed as four 3-byte values. Each 3 byte value holds four data samples – two
temperature readings and two humidity readings. These values are, however, not available
immediately and require processing before they can be stored as physical temperature and humidity
values.
8-bit Data
6-bit Data
b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 Temperature 1
b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 Temperature 2
b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 Humidity 1
LSB MSB
b7 b6 b5 b4 b3 b2 b1 b0 Humidity 2
LSB MSB
Figure 41: Data manipulation of measurement samples.
As illustrated in Figure 41 above, the two Most Significant Bits are extracted from each of the 3 bytes
– effectively resulting in four 6-bit values. These values must then be multiplied by a scaling factor to
convert them to a physical temperature or humidity value. All that then remains to do is to store these
values in an array so that the corresponding temperature and humidity values are next to each other.
This process then continues for the remaining bytes in the packet.
The 13th byte contains an “hour value”. The data contained in the first packet acquires a time stamp
based on the initial time stamp – this is achieved by simply incrementing the initial hour value and
41
adjusting the other time stamp parameters if necessary. After assigning the correct time value to the
data samples in the packet, the hour value is now forced to the value contained in the 13th byte. So, the
subsequent data samples all receive a time stamp based on the previous packet’s “hour value”. The
process is illustrated in Figure 42.
Figure 42: Synchronisation of Time Stamp
42
3 Housing
3.1 The Measurement Unit

The environment that this unit will be exposed to varies from the ceilings of houses to the inside of
caves. It was thus imperative that the housing be designed in such a way that the internal circuitry is
protected against all possible climatic conditions. The unit has also been designed with a female
header in order to allow easy docking with the Memory Unit.
The first issue that was addressed, due to the environments in which the devices will be placed, was
moisture. Humidity levels as well as small bodies of water are all conditions that the housing must
protect the circuitry against. In order to achieve water resistivity the housing is constructed out of
fibreglass with o-ring seals. The casing, however, had to be breached to create a hole for the sensor to
be exposed in order to measure air temperature and humidity. In order to maintain water resistivity
whilst not inhibiting the sensors ability to take measurements, the group intended on implementing the
SH1, a filter cap. However, procurement of the filter cap was very difficult and attempts at obtaining
the cap were unsuccessful. It was then decided that a seal around the sensor would be created using
silicon, which is innately a hydrophobic substance.
The housing must also be rugged enough to withstand accidental falls. To this end the external lid is
fastened with stainless steel retaining bolts and nickel plated brass inserts are used for securing the lid
and device plate. The walls of the housing are also thickened for extra strength and sturdiness.
Figure 43: Measurement Unit Housing
3.2 The Memory Unit

Even though the Memory Unit would be in the same environment as the Measurement Unit, it is not
imperative that this unit be water resistant or very robust as it is contained within the Measurement
Unit. It was thus decided to make this unit as light and compact as possible. The Memory Unit is
composed of the EEPROM mounted on a PCB with a set of male connectors. This minimalistic
43
approach was adopted to essentially imitate the SD card appearance and ease of use. A sufficiently
small enough casing for the PCB could not be found hence it was decided to omit housing.
Initially it was decided that an erasable writing surface will be adhered to the Memory Unit. On this
surface the date and time of activation of that particular unit would have been written. This was to be
done in order to ensure that in the event of time stamp data corruption the writing surface could be
used as a last resort to salvage the 6 months of data. However, this surface is no longer needed as time
stamp data is now taken every 8 hours thus the loss of 6 months of data is no longer a concern.
Figure 44: Memory Unit
3.3 The PC Interface Unit

The PC Interface Unit does not require any special housing due to the fact that it would not be used in
the field. This unit was thus made of ordinary hardened plastic with a female header attached to the lid
of the module, for docking with the Memory Module, and a USB cable. The housing is designed to be
aesthetically appealing as this unit will be used in a visible location near a PC.
Figure 45: PC Interface Unit
44
4 Module Tests
The Measurement Module was subjected to different temperatures, not exceeding those specified by
the range of operation of the system, and readings were taken. The changes in air temperature were
induced using a standard oil heater, to increase temperature, and an air-conditioned environment, for
reduced temperatures. These readings were then compared to a calibrated digital thermometer’s
readings taken at the same time. The results of these tests are shown in Graph 1 below.
Graph 1: Temperature Measurements
50
45
Temperature (degrees C)
40
35
30
System Output
25
20 Thermometer
15
10
5
0
1 2 3 4 5 6 7
Sample Number
As can be seen the system output closely tracks the thermometer readings taken. The largest error
between the two measurements was found to be 1.6˚C at thermometer measurements of 40.6˚C and
22.6˚C. This deviation from the accuracy achieved at 25˚C can be attributed to the inaccuracy of the
sensor at these temperatures.
Humidity was first tested by placing the measurement module in close proximity to boiling water. As
it is well known steam increases the moisture content of the surrounding air thus creating conditions of
increased humidity. Conditions of low humidity were induced by using a heater to dry the air. The
readings taken using the Measurement Module were then compared to those taken using a hygrometer.
Unfortunately, the hygrometer used was not very accurate - thus the readings taken by the hygrometer
were used merely as a rough estimate of the humidity to give the group an idea of region in which the
measurement unit’s readings should be.
45
5 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.
5.1 The Measurement Module

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 groups overall objectives - cost reduction.
5.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 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.
5.3 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
46
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 behaviour 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.
47
6 Costing
Quantity Component Description Manufacturer Unit Price(R) Total (R)
1 SHT71 Sensor Sensirion 210 210.00
1 DS1305 Real time clock Maxim 20 20.00
2 ATtiny2313 Microcontroller Atmel 40 80.00
1 AT24C64A EEPROM Atmel 10 10.00
3 Fibre glass Housing Enlec 90 90.00

box
1 USB Connector - 5 5.00

connector
4 AA batteries Batteries Energizer 5 20.00
1 Lithium Battery Panasonic 13 13.00

Battery
3 DB9 port Serial ports - 4 12.00
1 FT232RL USB UART IC FTDI 45 45.00
1 CSB384J Ceramic Murata 8 8.00

Resonator
TOTAL R 518.00
48
7 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 cost of the design is R518 in total, placing the group R18 over budget. The main expense in the
design is the sensor that was implemented. However, it was decided that this expenditure was worth
the 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.
49
References
[1].Sensirion-“Relative_Humidity_Basics” www.sensirion.com /,accessed on 23 February 2006
[2]. Energizer- “Lithium Coin Battery cr2016”, www.energizer.com/, accessed on 1 March 2006
[3]. Atmel Corporation- “AVR035: Efficient C Coding for AVR”, www.atmel.com/, accessed on 5
March 2006
[4]. Energizer- “Lithium Battery Considerations” www.energizer.com/, accessed on 1 March 2006
[5]. Sensirion- “SHT 1x / SHT7x Humidity and temperature Sensor”, www.sensirion.com / accessed
on 25 February 2006
[6]. “Using the SPI protocol”, www.avrhelp.mcselec.com/Using_the_SPI_protocol.html, accessed 11

March 2006
[7]. Atmel Corporation- “AVR310: Using the USI module as a I2C master “www.atmel.com/,
accessed on 11 March 2006
[8]. Atmel Corporation- “ATtiny2313 datasheet “, www.alldatasheet.com/ , accessed on 25 February

2006
[9]. Atmel Corporation- “Avr151: Setup and use of the SPI” , www.atmel.com/, accessed on 11
March 2006
[10]. Nanotron Technologies- “Wiring Configurations of the Serial Peripheral Interface”,

www.nanotron.com/ ,accessed 11 March 2006
[11]. Maxim - “Interfacing I2C Serial Real-Time Clocks to a Microcontroller”,
www.maxim-ic.com/AN3300, accessed 11 March 2006
50
[12]. Maxim- “Serial Alarm Real-Time Clock”, www.maxim-ic.com/AN3300, accessed 12 March
2006
[13]. Intersil Corporation “Real Time Clock X12xx Features & Application”, www.intersil.com,
accessed 11 March 2006
[14]. Maxim- “Application Note 701 Using the DS32kHz with Dallas RTCs” www.maxim-ic.com/,
accessed 14 March 2006
[15]. Maxium- “Lithium coin-cell batteries: predicting an application lifetime”, www.maxim-ic.com/

,accessed 23 February 2006
[16]. Energizer- “ENERGIZER NO. L91”, www.energizer.com/, accessed 21 March 2006
[17]. American Power Conversion Corporation “Real world battery life predictions”, www. apc.com/,
accessed 25 February 2006
[18]. NEC- “Power Consumption Optimization in NEC Electronics Microcontrollers”,

www.necelam.com/ , accessed 25 February 2006
[19]. Parallax- “Using the DS1302 Trickle Charge Timekeeping Chip”

www.parallax.com/dl/docs/prod/appkit/ds1302Rtc , accessed 25 February 2006
[20]. “A pointless guide to CRC error detection algorithm”,www.repairfaq.org , accessed 25

February 2006
[21]. Sensirion- “Non linearity Compensation” www.sensirion.com/ ,accessed on 25
March 2006
[22]. Sensirion- “CRC_Calculation” www.sensirion.com/ ,accessed on 23 February 2006
[23]. “Temperature sensors”, www.ysitetemperature.com , accessed on 23 February 2006

51
[24]. “Advantages and Disadvantages”, www.ysitetemperature.com , accessed on 24 February 2006
[25]. “Choosing an RTD, Thermocouple or Thermister” www.dataloggerstore.com , accessed on
24 February 2006
[26]. Atmel Corporation- “Interfacing AT24CXX Serial EEPROMs with AT89CX051
Microcontrollers”, www.atmel.com/, accessed on 11 March 2006
[27]. Atmel Corporation- “AVR402:Hardware design considerations” , www.atmel.com/,
accessed on 28 March 2006
[28]. Future Technology Devices - “AN232B-05 Configuring FT232R,FT2232C and FT232BM
Baud Rates” , http://www.ftdichip.com ,accessed 16 March 2006
[29]. Future Technology Devices – “AN232R-02 FTDIChip-ID™ for the FT232R and
FT245R”, http://www.ftdichip.com ,accessed 16 March 2006
[30]. Future Technology Devices “FT232R USB UART I.C”, http://www.ftdichip.com ,accessed
16 March 2006
52
Contacts
Much of the design decisions in the project have been made in consultation with researchers who
would possibly use such a device. Their contact details have been listed below.
Claire Peterson
Manager: Bat Conservation Group
ewt@ewt.org.za
Eleanor Richardson
Bat Researcher
ejrichardson@worldonline.co.za
Mike Devlin
The Endangered Wildlife Trust
mdevlin512@aol.com
Peter Taylor
Durban Bat Interest Group
petert@crsu.durban.gov.za
Nigel Fernsby
Guateng and Northern Regions Bat Interest Group
fernsby@netactive.co.za
53
Appendix A
Average Sensor Supply Current Calculation
Current required during measuring (IM): 550µA
Current required during sleep (IS): 1µA
Time taken to measure temperature: 55ms
Time taken to measure humidity: 11ms
Total active time: 66ms
Let us assume that at worst case the active cycle (tA) is 100ms.
Current for 1s of operation (active cycle):
If the sensor is active for 100ms then it will be in sleep mode for tS=900ms
I SHT = I M t A + I S t S
= (550 × 10 −6 )(100 × 10 −3 ) + (1 × 10 −6 )(900 × 10 −3 )
(
= 55 × 10 −6
) + (900 × 10 −9
)
= 55.9 × 10 −6 A.s
Average Current drawn over an hour:
The current drawn is averaged over an hour as this is the length of the sampling period employed. The
active cycle is included in the calculation above and current drawn for one second will be included in
the calculation below to cater for the active cycle
I AVG _ SHT = I SHT + I S (3600 − 1)
= 55.9 × 10 −6 + (1 × 10 −6 )(3599 )
= 3.65 × 10 −3 A.hrs
54
Convert to Amperes
I AVG
I AVG _ SHT =
3600
= 1.015 × 10 −6 A
Power Calculation for EEPROM
(I idle × t idle ) + (I active × t active )

The average current may be calculated by I avg = .
t total
Figure 46: The Current Characteristics of the AT24C64A
The AT24C64A has the following electrical characteristics at Vcc = 5V :
Iwrite Iidle twrite tidle ttotal
3mA 2µA 1 sec 3599 sec 3600 sec
The electrical characteristics above yield an average current of 2.83µA .
The write operation draws three times as much current as a read operation. To achieve a worst case
power scenario for the EEPROM, all communications with the EEPROM is assumed to be a write
operation.
Power Comparison between Microcontroller Based RTC and Dedicated RTC
Figure 38 below shows how the current drawn by the microcontroller varies.
55
Figure 38: Current Characteristic of ATmega16L
The average current may be calculated by I avg =

(I idle × t idle ) + (I active × t active )
t total
The microcontroller’s electrical characteristics at Vcc = 2V are:
Iidle Iactive tidle tactive ttotal
2mA 5mA 14.999975 s 25 µs 15 s
These values yield an average current of 2mA.
Figure 39: Current Characteristics of the DS1305
The electrical characteristics of the DS1305 at Vcc = 2V are:
0.4mA 0.3µA 3599 seconds 1 second 3600 seconds
The above values yield an average current of 0.3µA. The DS105 communicates with the
microcontroller during its active cycle. During this period, the microcontroller draws a current from
the main supply. The RTC uses the microcontroller’s internal pull-up during its idle time. The 50kΩ
resistor sources 92µA from the main 4.5V power supply. This means that the electrical characteristics
of the microcontroller changes to:
92µA 0.35mA 3599 seconds 1 second 3600 seconds
The microcontroller therefore draws 92.1µA.
56
This implies that the total current drawn by the DS1305 method, is 0.3µA + 92.1µA = 92.4 µA , which
is lower than the current drawn by a microcontroller based method.
Power Calculation for Microcontroller
Assume that the active cycle of the microcontroller takes 1s hence for the rest of the sample period,
3599s; the microcontroller will be in a power down mode. The active current for the microcontroller is
given as 1.1mA whilst the current drawn in power down mode was found to be 216.25µA, due to
internal pull ups being utilised. Figure below shows how the current drawn by the microcontroller
varies during sampling periods.
Figure 47: Current Characteristic of ATMega16L
The microcontroller’s electrical characteristics at Vcc = 3V are summarized in the table below:
Ipowerdown Iactive Tpowerdown tactive ttotal
180µA 1.1mA 3599 s 1s 3600 s
The average current may be calculated by I avg =

(I powerdown × t powerdown ) + (I active × t active )
.
t total
These values yield an average current of 180.26µA.
57

Design of A Data Logger

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Design of A Data Logger

Hochgeladen von

Copyright:

Verfügbare Formate

COURSE: Electronic Design 3

REPORT ON: Design of a Data Logger (Phase 3 Report)

REPORT BY: Group 6 (Corresponding Author: Muhammad Simjee - simjeem@gmail.com)

Irisa Govender 203502431

Mark Joseph 203504473

Nicol Naidoo 203503153

Seeralin Nayager 203505544

Muhammad Simjee 203503366

Shivan Singh 202511992

1.2 Physical Implementation........................................................................................................ 4

1.3 Proposed Operation................................................................................................................ 5

2.1 Measurement Module ............................................................................................................ 5

2.1.1 Measurement Unit ............................................................................................................. 5

2.1.1.1 Temperature and Humidity Measurement ................................................................ 5

2.1.1.2 Time Stamping.......................................................................................................... 9

2.1.1.3 Control .................................................................................................................... 15

2.1.2 Memory Unit ................................................................................................................... 15

2.1.2.1 Sampling Rate......................................................................................................... 16

2.1.2.2 Data Storage............................................................................................................ 16

2.1.2.3 Measurement Data .................................................................................................. 16

2.1.2.4 Time Stamped Data................................................................................................. 17

2.1.2.5 Physical Implementation......................................................................................... 17

2.1.2.6 Power Consumption................................................................................................ 18

2.1.2.7 Writing to EEPROM............................................................................................... 18

2.1.2.8 Development and Testing of EEPROM Software .................................................. 20

2.1.3 System Operation ............................................................................................................ 22

2.1.3.1 Tasks Required ....................................................................................................... 22

2.1.3.2 Sampling and Storage of Base Time Stamp............................................................ 22

2.1.4 Complete Circuit Diagram............................................................................................... 26

2.1.5 Construction of Measurement Module ............................................................................ 28

2.2.1 Hardware Requirements .................................................................................................. 29

2.2.2 The Download Procedure ................................................................................................ 30

2.2.2.1 Communication Protocol ........................................................................................ 31

2.2.2.2 USART Communication......................................................................................... 32

2.2.2.3 EEPROM read process ........................................................................................... 33

2.2.2.4 Actual download procedure .................................................................................... 35

2.2.2.5 The Visual Basic Graphical User Interface............................................................. 39

2.2.2.6 Data manipulation using PC software..................................................................... 40

3.1 The Measurement Unit ........................................................................................................ 43

3.2 The Memory Unit ................................................................................................................ 43

3.3 The PC Interface Unit .......................................................................................................... 44

4 Module Tests ................................................................................................................................. 45

5 Analysis of Design ........................................................................................................................ 46

5.1 The Measurement Module ................................................................................................... 46

5.2 The PC Interface Module..................................................................................................... 46

Average Sensor Supply Current Calculation......................................................................................... 54

Power Calculation for EEPROM .......................................................................................................... 55

Power Comparison between Microcontroller Based RTC and Dedicated RTC.................................... 55

Power Calculation for Microcontroller ................................................................................................. 57

ISR - Interrupt Service Routine

LED - Light Emitting Diode

RTC - Real time clock

MSB - Most Significant bit

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

GUI - Graphical User Interface

USART - Universal Synchronous Asynchronous Receiver Transmitter

BCD - Binary Coded Decimal

Table 1: Overall System Tasks and Constraints