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 - [email protected])

Irisa Govender 203502431

Mark Joseph 203504473

Nicol Naidoo 203503153

Seeralin Nayager 203505544

Muhammad Simjee 203503366

Shivan Singh 202511992

ii

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.

iii

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

iv

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

v

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

1

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

2

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

3

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

4

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

5

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

6

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

7

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.

8

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

9

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

10

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:

sec10256.01024

4 3

1

−

−

×=

=

Mhzperiod

Using the 16 bit timer implies that a maximum count of sec777.16sec10256.02 316 =×× −. 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:

( ) ( ) 436910256.015777.16 3 =×÷− −

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 2ccV 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 AI average µ3.0= . 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

11

average

serviceI

Capacityt = .

hrsA

mAht service

3103003.0

90×==

µ

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.

Crystal

3V battery

2

3

4

5

39

38

37

36

6

7

8

9

35

34

33

32

140

10

11

12

13

31

30

29

28

GND

14

15

16

17

27

26

25

24

1823

1922

2021

ATmega16L

1

4

3

2

5

6

7

8

16

15

14

13

12

11

10

9

RTC

Vcc2

SDO

Vcc1

INTO

Vbat

CE

SCLK

SERMODE GND

SDI

SS

MISO

MOSI

SCK

INT0

VccIF

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.

12

Master Initialistaion

SS, MOSI, SCK => o/p

pins

MISO => i/p pin

Set bits SPE and MSTR of

SPCR register.

Clear SPI interrupt flag by

reading SPSR and SPDR.

SPDR = main_data

Wait for SPI interrupt

flag



SPDR = arb_data


flag

Ouput main_data

to LED’s

End process

Slave Initialistaion

SS, MOSI, SCK => i/p pins

MOSI => o/p pin

Set bit SPE of SPCR

register.




flag

End processNo

Yes

No

Yes

No

Yes

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.

13

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

SS, MOSI, SCK => o/p

pins

MISO => i/p pin

Set bits SPE and MSTR of

SPCR register.

End process

No

Transmit_data



SPDR = data

Call Transmit_data


flag

Yes

Return

No

All time info sent?

Yes

Call Transmit_data

Enable SPI on RTC

Disable SPI on RTC

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.

14

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’ 0NTI 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.

15

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.

16

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

17

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.

18

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.

19

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.

20

Start

Read in TWI Control

Register

Clear lower 7 bits of

TWCR

TWINT flag

set?NO

YES

TWI_Stat

Read in TWI Status

Register

Mask Lower 3 Bits of

TWSR

Pass masked version of

TWSR back to EWrite

Start

Figure 18: Flow Diagram of TWI_Stat

TWI_Initialisation and TWI_Stat make up the bulk of the procedure EWrite, which is utilised to write to EEPROM. EWrite obtains the 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 through the Two Wire Interface. The EEPROM’s slave address is loaded and sent. EWrite comprises a number of loops where TWI_Stat is called. These loops allowed for testing of the software during the development phase. The following section describes the development and testing of the software to write to EEPROM.

2.1.2.8 Development and Testing of EEPROM Software

For the development process, the EEPROM was connected in a similar manner to that described in Figure 16, but with the EEPROM on a 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 therefore possible to test the operation of the code by lighting up the Light 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 chosen to represent the value of the loop position (indicated beside the decision boxes in the diagram beside).

When an error occurred, the number of the last correctly executed loop was determined from the LEDs on the STK board. The EWrite code was then re-examined and edited to output the value of TWSR in order to

Start

Call TWI_Initialisation

Start Condition sent?

NO

Send Slave Address and Write Command

YES

Slave Address

sent?

NO

YES

Send Higher Byte of Data Address

Call TWI_Stat

High Byte of Data Address sent?

YES

Send Lower Byte of Data Address

Low Byte of Data Address sent?

NO

NO

YES

Send Data

Acknowledge Received

NO

More Data to Send

YES

NO

Send Stop Condition

YES

END

Call TWI_Stat

Call TWI_Stat

Call TWI_Stat

Call TWI_Stat

1

2

3

4

5

21

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.

22

- - - - - - - n - - - - - - -

0x00

0x01

Number of Samples

Taken (2 bytes)

- - - - - - - - - - - - - - - - - - -Hour

Date- - - - - - - - - - - - - - - - - - -

Month- - - - - - - - - - - - - - - - - - -

Year 0x06

0x02

Time Stamp Data

(4 Bytes)

Measured

Data

0x07

0x09

n1 → n2 (Temperature

and Humidity Data)

Measured

Data

0x0A

0x0C


and Humidity Data)

Measured

Data

0x0D

0x0F


and Humidity Data)

Measured

Data

0x10

0x12


and Humidity Data)

0x13Hour

0x14

Time Stamp

Synchronisation

Measured

Data

n4391 → n4392

(Temperature and

Humidity Data)

0x1BE0

0x1BE2

0x2000

Reserved

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.

23

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

24

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

Mode

Active Mode(Interrupt Service

Routine)

If Interrupt Occurs

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.

25

Figure 22: Hourly Interrupt Routine

26

4

2.1.4 Complete Circuit Diagram

Using the requirements of the individual components the complete circuit diagram of the measurement module was created.

Crystal

3V battery

2

3

4

5

39

38

37

36

6

7

8

9

35

34

33

32

140

10

11

12

13

31

30

29

28

GND

14

15

16

17

27

26

25

24

1823

1922

2021

ATmega16L

1

4

3

2

5

6

7

8

16

15

14

13

12

11

10

9

RTC

Vcc2

SDO

Vcc1

INTO

Vbat

CE

SCLK

SERMODE GND

SDI

SS

MISO

MOSI

SCK

INT0

VccIF

SCL

SDA

PC3

PC2

1A0

2A1

A23

GND4

8

7

6

5

Vcc

WP

SCL

SDA

AT24C64A

VCC

GND

RESET

XTAL2

XTAL1

VCC

14

23SHT71

VDDGND

SCKDATA

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.

27

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.

MICROAVGEEPAVGSHTAVGTOTAL IIII ___ ++=

666 1026.1801083.210015.1 −−− ×+×+×=

A61010.184 −×=

Number of hours the battery must source current for = hrsdays 24183 ×

hrs310392.4 ×=

Hence the rating of the battery should be hrsITOTAL ×=

)10392.4)(1010.184( 36 ××= − hrsmA.59.808=

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.

Lifespan (hours) TOTALI

rating=

6

3

101.184

105500−

−

×

×=

28

hrs31088.29 ×=

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.

29

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.

30

4

5

6

7

25

24

23

22

AGND

8

9

10

11

21

20

19

18

12

13

14

17

16

15

3

2

1

26

27

28TXD

RXD

VCCIO

GND

GND

GND

TEST

CBUSO

3V3OUT

USBDP

USBDM

FT232RL

VCC

2

3

4

5

39

38

37

36

6

7

8RESET

9

35

34

33

32AREF

140

10VCC

11

12

13

31

30

29

28

GND

AVCC

14RXD

15TXD

16

17

27

26

25

24

PC3

PC2

1823SDA

1922SCL

2021

ATmega16L

1A0

2A1

A23

GND4

8

7

6

5

Vcc

WP

SCL

SDA

AT24C64A

TO USB PORT

RESET4k7

VCC

FERRITE

BEAD

4.7uF 100nF

100nF

100nF 4.7uF

10nF

47nH

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

31

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

n

hours

date

month

year

Number of Samples

Base Time Stamp

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

32

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.

Measurement Data

Block (13 bytes)

Checksum

Initialization Data Block

(6 Bytes)

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.

33

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.

34

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.

35

Start

Resend Device

Address

Call TWI_Stat

Address Sent?NO

YES

Wait

TWINT Flag Set?NO

YES

Read in Data

Pass Data to Main

More Data to

Read?

YES

Send

Acknowledgement Bit

No

Acknowledgement

Send Stop

Condition

End

NO

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:

36

Microcontroller waits

for start condition

User invokes start

condition by clicking

“Download”

Microcontroller PC

Initialization Block(+

Checksum)

Transmitted


for Acknowledge

Checksum is verified

and Acknowledge

Transmitted

Measaurement Block(+

Checksum)

Transmitted Checksum is verified

and Acknowledge

Transmitted


for Acknowledge

Measaurement Block(+

Checksum)

Transmitted Checksum is verified

and Acknowledge

Transmitted

start

Data

ACK

Data

ACK

Data

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.

37

Figure 33: Process describing block data transfer.

The diagram below indicates the entire microcontroller operation in the PC Interface Module.

Wait for Start

Read address 0x00 – 0x05

of EEPROM

(Initialization Data)

Start Condition

Recieved

Yes

No

Compute Checksum

Transmit Function

Read address n – (n + 8)

of EEPROM

(Measurement Data)

Compute Checksum

Transmit Function

n = n + 8

n = 6

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”

38

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.

“Start” condition sent

to microcontroller

Data packet received

by PC with Checksum

PC processes Data

PC Recalculates

Checksum

Transmit ACK to

Microcontroller

PC_Checksum =

Received_Checksum?Discard packet

True

False

Wait

Click Download

Figure 35: Download process between PC and microcontroller.

39

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

40

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

41

BCD value.

b8 b5b6b7 b4 b1b2b3

Read

BCD Value

Convert to DecimalConvert to Decimal

And Multiply by 10

Add Upper & Lower

Values

b8 b5b6b7 b4 b1b2b3

Convert to 8-bit Binary

Separate Upper and

Lower nibbles

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.

b7 b6 b5 b4 b3 b2 b1 b0

b7 b6 b5 b4 b3 b2 b1 b0

b7 b6 b5 b4 b3 b2 b1 b0

b7 b6 b5 b4 b3 b2 b1 b0

6-bit Data

b7 b6 b5 b4 b3 b2 b1 b0

b7 b6 b5 b4 b3 b2 b1 b0

b7 b6 b5 b4 b3 b2 b1 b0

b7 b6 b5 b4 b3 b2 b1 b0

8-bit Data

Temperature 1

Temperature 2

Humidity 1

Humidity 2

MSB

MSBLSB

LSB

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

42

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

43

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

44

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

45

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

0

5

10

15

20

25

30

35

40

45

50

1 2 3 4 5 6 7

Sample Number

Te

mp

era

ture

(d

eg

ree

s C

)

System Output

Thermometer

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.

46

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

47

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.

48

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 box

Housing Enlec 90 90.00

1 USB connector

Connector - 5 5.00

4 AA batteries Batteries Energizer 5 20.00

1 Lithium Battery

Battery Panasonic 13 13.00

3 DB9 port Serial ports - 4 12.00

1 FT232RL USB UART IC FTDI 45 45.00

1 CSB384J Ceramic Resonator

Murata 8 8.00

TOTAL R 518.00

49

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.

50

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

51

[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

52

[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

53

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

[email protected]

Eleanor Richardson

Bat Researcher

[email protected]

Mike Devlin

The Endangered Wildlife Trust

[email protected]

Peter Taylor

Durban Bat Interest Group

[email protected]

Nigel Fernsby

Guateng and Northern Regions Bat Interest Group

[email protected]

54

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

SSAMSHT tItII +=

( )( ) ( )( )3636 109001011010010550 −−−− ××+××=

( ) ( )96 109001055 −−×+×=

6109.55 −×= 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

.

( )13600_ −+= SSHTSHTAVG III

( )( )3599101109.55 66 −− ×+×=

hrsA.1065.3 3−×=

55

Convert to Amperes

3600_

AVG

SHTAVG

II =

A610015.1 −×=

Power Calculation for EEPROM

The average current may be calculated by( ) ( )

total

activeactiveidleidleavg

t

tItII

×+×= .

Figure 46: The Current Characteristics of the AT24C64A

The AT24C64A has the following electrical characteristics at VVcc 5= :

Iwrite Iidle twrite tidle ttotal

3mA 2µA 1 sec 3599 sec 3600 sec

The electrical characteristics above yield an average current of Aµ83.2 .

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.

56

Figure 38: Current Characteristic of ATmega16L


total

activeactiveidleidle

avgt

tItII

×+×=

The microcontroller’s electrical characteristics at VVcc 2= 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 VVcc 2= 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.

57

This implies that the total current drawn by the DS1305 method, is AAA µµµ 4.921.923.0 =+ , 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 VVcc 3= are summarized in the table below:

Ipowerdown Iactive Tpowerdown tactive ttotal

180µA 1.1mA 3599 s 1s 3600 s


total

activeactivepowerdownpowerdown

avgt

tItII

×+×= .

These values yield an average current of 180.26µA.

Date post:	11-Apr-2015
Category:	Documents
Upload:	muhammad-simjee
View:	5,493 times
Download:	6 times

Design of a Data Logger

Documents