Low-Cost Aeroponic Plant Growth Chamber

Final Report

May 11-22

Advisor:

Prof. Timothy Bigelow

Team Members:

Zachary Davis

Mohammed Rahim

Christopher Reeve

Daniel Wright

April 27, 2011

ContentsExecutive Summary........................................................................................7Problem Statement.........................................................................................8Market Survey.................................................................................................8End Product & Major Deliverables.................................................................8System Design.................................................................................................9

System Description......................................................................................9Introduction..............................................................................................9Chamber Environment..............................................................................9Control Environment..............................................................................10Sensors and control hardware................................................................10

Functional Requirements...........................................................................10Non-Functional Requirements...................................................................11Assumptions and Considerations...............................................................11System Decomposition...............................................................................12

Operating Environment.................................................................................12Operating Parameters................................................................................13

Detailed Design.............................................................................................13Chamber Design.........................................................................................13

Chamber Design Drawings.....................................................................15Chamber Design Front View...............................................................15Chamber Design Side View.................................................................16Chamber Design Full View..................................................................17

Chamber Implementation Images..........................................................18Chamber Implementation Image 1......................................................18Chamber Implementation Image 2......................................................19Chamber Implementation Image 3......................................................20Sprayer Image.....................................................................................21

Chamber Parts........................................................................................21Software Specification...............................................................................22

Web User Interface.................................................................................22Master Page.........................................................................................22Login....................................................................................................22Default.................................................................................................22Data.....................................................................................................22Settings................................................................................................23Additional Functions............................................................................23

Server User Interface.............................................................................23

2

Central Server Program..........................................................................23Microcontroller.......................................................................................26

Software Documentation...........................................................................27Compiled Documentation.......................................................................27Source Version Control...........................................................................27

Software Testing........................................................................................29Strategic Unit Tests................................................................................29

Serial Communication.........................................................................29Socket Receive Protocol......................................................................30

Electrical Design........................................................................................30Power......................................................................................................30Microcontroller.......................................................................................30Sensors...................................................................................................31Sound......................................................................................................31Depth Sensor..........................................................................................32

PCB Design................................................................................................33PCB.........................................................................................................33Schematic...............................................................................................34Parts List.................................................................................................35

Budget & Schedule.......................................................................................36Budget........................................................................................................36Schedule.....................................................................................................36

References.....................................................................................................37Contact..........................................................................................................38Appendix I – Sound Fourier Transform Captures.........................................39

Constant Tone (1kHz)................................................................................39Random Noise (1kHz Center Frequency)...............................................39

Appendix II – Development Setup Instructions.............................................40Chamber.....................................................................................................40Server App.................................................................................................40Web Server.................................................................................................40

Appendix III – User instructions...................................................................41Appendix IV - Texas Instruments Parts.........................................................42

CD40109B..................................................................................................42OPA548T....................................................................................................42PTN78020A................................................................................................42TMP100......................................................................................................42μa741.........................................................................................................43

Appendix V – Serial Command Protocol........................................................44

3

Table of Contents.......................................................................................441 Key.......................................................................................................442 Protocol................................................................................................443 Commands...........................................................................................444 TASK_GET_SAMPLES..........................................................................455 TASK_UPDATE_SETTINGS..................................................................45

Appendix VI - Python Dependencies.............................................................46

4

5

Executive Summary

As humans, our lives necessitate the need for food. This food comes from many sources, one of them being plants. Since this is important to our very survival, there is a need for research to produce disease resistant and quicker producing plants. In order to conduct research there needs to be a controlled environment, which allows a researcher to change different variables in the growth of a plant to see what effects it has. Many of these controlled environments employ the use of aeroponics to grow the plants. The use of aeroponics is also undergoing research as a way to grow plants easier in space. Since aeroponics uses less water than either hydroponics or geoponics this could be beneficial on extended excursions.

The goal of our senior design project was to have a low cost controlled plant growth chamber that utilizes aeroponics. Growth chambers that are currently on the market can cost nearly $100,000, so a cheaper alternative would greatly enhance research that is being performed. In order for our chamber to be a serious competitor, we need to have the same types of sensors offered by the current solutions. This means that our chamber has temperature, humidity, and CO2 sensors. We also have the ability to keep a consistent temperature, provide nutrients to the plants, have a consistent airflow, and give the plants light. Professor Bigelow would like to research whether or not sound has an effect on plant growth and healing. Therefore, our chamber has speakers and controls in order to play random frequencies in a specified bandwidth ranges so that Professor Bigelow may perform his experiments. Beyond this, we have the ability to control the settings for multiple chambers from one central location.

6

Problem Statement

Many disciplines do research with plants and need a controlled growth environment. Existing growth chamber solutions available are far too expensive for typical use in research. Our team’s task was to design and build an economically feasible controlled environment for the growing and monitoring of plants using aeroponics. Such a system has many applications in research and other fields.

Market Survey

In order to get a better understanding of aeroponics and plant growth chambers our group had a meeting with Dr. Richard Gladon from the Department of Horticulture here at Iowa State University. He informed us of what parameters needed to be monitored in order to have research be considered valid. This is what determined the types of sensors that we needed and what data we report to the user. He also suggested that we design a growth chamber that can accommodate tomatoes. These are the simplest to grow and are common for an initial study. We were unable to find any other controlled environment growth chambers using areoponics produced or sold on the market.

End Product & Major Deliverables

Ending our project, we have these documents up to date and delivered: Project Plan Design Document Final Report Project Poster

Our end product is one aeroponic growth chamber. This chamber has the ability to keep a consistent temperature while monitoring CO2, humidity level, and temperature. There is also the ability to have an audible tone played and a light turned on and off. All of these are then user defined. Users can log onto a web server or web user interface in order to change the settings of the chamber. The settings are communicated to the chamber via a wireless link.

7

System Design

System Description

Introduction

The system has three major components. The first is the chamber environment. This is the physical environment, such as temperature and humidity that the system has to monitor and control. The second part is the control block. This part is responsible for monitoring and affecting the chamber environment through sensors and heaters etc. This consists of a microcontroller and the application software, not the sensors themselves. The third part of the system is the physical sensors and other environment modifiers such as heaters and water pumps. This part of the system provides feedback to the control system on the chamber environment.

Chamber Environment

The physical attributes of the growing chamber, hereafter simply ‘the chamber’, is where the plants grow. There are a number of factors that must be carefully monitored and some that must be controlled. According to the International Committee for Controlled Environments, the minimum measuring and reporting guidelines are:

Radiation Temperature Atmospheric Moisture Carbon Dioxide Air Velocity Watering pH Electrical Conductivity Substrate Nutrition Chamber dimensions

For our project, it is not necessary to monitor or report substrate, as aeroponic growing uses no substrate. Of the remaining parameters, only the watering and radiation is actively changeable with our setup; the rest are simply monitored and reported.

The chamber itself consists of a large enough housing for the plants to remain suspended through their growth cycle, as well as all the hardware required to vent, water, light, heat/cool, and drain the plants growing inside.

8

Control Environment

The control environment for the system consists of a microcontroller interfaced to the various sensors that are responsible for reporting the current conditions and activating the active elements (heater, pump, light, etc.). The microcontroller is able to remotely communicate with a separate computer that serves as a database and web server. With the computer, lab technicians are able to monitor the current state and activate or schedule active elements. This system consists of both hardware and software elements.

Sensors and control hardware

A wide array of sensors is required to properly monitor the parameters required. In addition, the chamber provides a way to vent, light, and water the plants inside. The sensors must be accurate and able to withstand the humid environment of the chamber. The light, water pump, and ventilation fans must be easily controllable with a microcontroller.

Functional Requirements

1. To build a low-cost (not to exceed $500), controlled, aeroponics plant growth chamber.

2. The light source should emit radiation in the Photosynthetically Active Radiation (PAR) spectrum (400 to 700 nm).

3. Air velocity inside the chamber should be between 0.3 and 0.7 m/s.4. The chamber should be maintained at an optimum temperature (for

tomato plants) of 68F during light hours, and 77F during dark hours.a. The temperature sensor should have a minimum resolution of

1F.5. To prepare the correct Hoagland solution Type I, an industrial

standard in growth chamber research, to provide nutrients to the plant in an aeroponic setting.

a. The pH should be maintained between 5.5-6.5.6. To have the capability to administer sound (noise) to the plants inside

the growth chamber to investigate its effects (if any).a. The sound level should be 90-100 dB.b. Frequencies in the 1-16 kHz octave bands are acceptable

9

7. To have the capability to control and monitor various environmental parameters from a remote server. The parameters that need to be controlled are:

a. Radiation (Light)b. Temperaturec. Air velocityd. Wateringe. Sound

Non-Functional Requirements

1. To monitor, measure, and report the following parameters as required by North Central Extension & Research Activity–101 (NCERA-101):

a. Atmospheric moisture inside the chamber (Relative Humidity (RH))

b. pH and Electrical Conductivity (EC) of the nutrient solutionc. Substrate (this will be air for our aeroponic growth chamber)d. Nutrition (Hoagland solution Type I)e. Chamber properties:

i. Specifications (floor area)ii. Barrier beneath lamps (whether present and its

composition)iii. Air flow (whether up, down or horizontal)

2. To build a web interface to monitor and control various physical parameters (as indicated above) inside the growth chamber.

Assumptions and Considerations

1. The degree of accuracy of humidity sensors required for plant growth is generally unknown. We will assume an accuracy of ±3%

2. The chamber needs to be well ventilated to prevent CO2 accumulation or depletion. We will have frequent air exchanges (2 air exchanges per hour) for this purpose.

3. The roots of the plants must be kept in the dark; otherwise, the roots may develop the ability to photosynthesize.

4. The air temperature, CO2 and relative humidity need to be measured at the top of the plant canopy; the position of the sensors will be fixed, and therefore, the measurements may not be taken at exactly the top of the canopy as the plants grow.

10

5. Ideally, two chambers would have to be built, with one used as control, to investigate the effects of sound on plants; however, the available budget is not sufficient to build two chambers.

System Decomposition

Microcontrollers Pump Light Speaker Output Heating Coil Depth Gauge Temperature CO2

Humidity Python server application

Communicates between user interface and microcontroller Handles settings and periodic tasks

User Interface Web application to view data and change chamber settings Server application to change settings

Operating Environment

The operating environment for our project consists of the physical environment that the growth chamber is placed in. It does not consist of the environment inside the growth chamber, thought it may effect it. The growth chamber gets its air from the outside environment, so conditions such as temperature and humidity do affect it to some degree.

11

Operating Parameters

The growth chamber is designed to be placed in a relatively stable lab setting. The chamber does have some facilities to change its internal temperature and humidity, but these are not effective outside a certain range. This range is determined by the insulation factor of the chamber walls, but in general should be limited to between 50 and 90 degrees Fahrenheit. There are many reasons for this limitation, the most important of which is that the plumbing and mineral water tank are not insulated. Freezing temperatures would render the irrigation system inoperable, and possibly damaged. The exterior of the chamber is not waterproof, so it should not be placed in a location that is very moist or where there is a possibility of rain.

Some plant growth chambers on the market today are of a chamber-in-a-chamber design. Our chamber does not have this requirement; it is self-sufficient as long as the operating environment is kept to the reasonable levels stated above.

The aeroponics growth chamber requires a stable, moderate, and dry environment in which to grow plants. The environment is free to fluctuate in a normal fashion, within the operating parameters, and the chamber will be able to maintain a reasonable environment for growing plants.

Detailed Design

Chamber Design

The physical considerations of the growth chamber were such that it was necessary to design and manufacture the chamber ourselves. This consideration had the ramification that we had to alter our requirements so that we were capable of building the box ourselves, with what resources we had.

Because the chamber is subject to some amount of moisture, we chose to use exterior grade ¾-inch plywood. This plywood is strong enough to hold up against years of use while still being easy to work with. We chose plywood over Plexiglas because of its durability, rigidity, opacity, and easy of machining and joining. Plywood was also a reasonable choice because a member of our team had the required skills and tools available to make manufacturing the box easy. The inside of the box is coated with deck sealant, to protect it from moisture. Deck sealant was a better choice than exterior grade paint because it is specifically designed to hold up to

12

standing water. Exterior grade paint would have been an OK choice, but deck sealant is better for our purposes.

The dimensions of the chamber were decided upon after consulting with a member of the Iowa State department of horticulture, Dr. Gladon, a leading researcher in plant growth chambers. With his valuable advice, we constructed a plan for the chamber. The requirement was to be able to grow four plants at a time in the chamber, with each plant having plenty of space to grow, both horizontally and vertically. A floor plan of 20 inches square, each plant has 10 inches square of horizontal growth space. The distance between the growth light (and top of the chamber) was chosen to be 20 inches, ample space for a tomato plant to grow to maturity. The roots were allotted 14 inches of vertical space, which gives room for the roots to dangle and space for the misters. Added to the chamber were legs, which elevate it to a comfortable working level as well as providing space for a container that the chamber can drain into. There are two doors on the chamber, one for the upper plant part and one for the lower root portion. This separation gives the user more flexibility and control over how the plants are exposed. It also made the construction simpler in some ways. The doors are big enough to allow the user to remove the plants without damage. The doors use standard hook and eye latches to keep them closed. The doors are sealed against moisture using adhesive backed foam strips. These strips run the perimeter of the doors and keep moisture and some sound from escaping.

The irrigation system is based on a set of sprayers driven by a pump. The sprayers are arranged in the lower portion of the chamber where the roots are. There is one sprayer for each of the four plants. The sprayers are arranged such that the direction of spray is upward and toward the roots. The sprayers are fed by a pump that is supplied by a tank of nutrient solution. In order to use the pump we have available, it is necessary to run the water in a closed loop, back to the tank. We use a ball valve to control the pressure in the pipes. Any waste solution that collects in the chamber is carried away by a drainpipe installed in the bottom of the chamber. The bottom of the chamber was build with a gradient, to encourage solution to flow towards the drain. The water that comes from the drain is also directed back to the solution tank.

Testing the chamber itself was very straightforward. The most basic consideration is: “will it allow plants to grow?” Plants have few requirements, only light water and air. These are provided by the growth light, the sprayers, and the ventilation system. However, these are external to the chamber itself. The chamber provides a secure and stable platform for our sensors to run off.

13

Chamber Design Drawings

14

Chamber Design Front View

15

Chamber Design Side View

16

Chamber Design Full View

17

Chamber Implementation Images

Chamber Implementation Image 1

18

Chamber Implementation Image 2

19

Chamber Implementation Image 3

20

Sprayer Image

Chamber Parts

Manufacturer Part # Description QuantityACF Greenhouse N/A Mister Head 4ACF Greenhouse N/A PVC Adapter 4Boss Audio MR60W Boss Audio 6.5" 200 Watts 2-Way

Marine Speaker2

Cool Master SAF-S12-E1 120mm Case Fan 2Digi International WRL-08687 XBee Explorer USB 1Digi International XBee XB24-Z7WIT-004 XBee 2mW Wire Antenna - Series 2 (ZB) 1EarthLED GrowCube Pro 45 Watt LED Grow Light 1Fairchild Semicondutcor

1N4148 Small signal diode 3

Logisys PS550ABK 550Watts ATX12V Power Supply 1N/A N/A 1kΩ Resistor 6N/A N/A 10kΩ Resistor 3N/A N/A Heating Cord 1SHURflo 2088-594-154BX Standard demand pump 1Sparkfun COM-09096 Relay Control PCB 3Sparkfun BOB-09169 Breakout Board for AD9835 Signal

Generator1

ST Microelectronics 2N3904 Small signal NPN transistor 3Tyco Electronics PB1014-ND Power Relay 3Tyco Electronics 1776244-2 2 pin screw terminal 3Tyco Electronics 1776275-3 3 pin screw terminal 3

21

Software Specification

Web User Interface

A web user interface was made in order to allow remote monitoring of chambers and setting of tasks. This UI is an ASP.NET application produced in Visual Studio 2010. The HarvestField CSS template by Styleshout was used to give the site a uniform and appealing look. Communication to the Python application is done via sockets and JSON. A MySQL database holds all data collected and other information needed for the website and for the system as a whole.

Master Page

The master page contains the main parts of the website that appear on every page. This mostly means the CSS styling, but also includes the home and login/logout links. The navigation bar buttons are not included on the Master page because it could not correctly handle setting the current page graphic. A ContentPlaceHolder is in the nav bar and every child page must add the buttons itself. There are also ContentPlaceHolders in the header, side panel, and main panel.

Login

Forms Authentication is used to control page access. All pages except for Default.aspx (the home page) require a user to be logged in, in order to view the page. When a user tries to access a page that he or she doesn't have permissions for, they are automatically redirected to the login page. After logging in, they are returned to the page that they tried to access. Accounts must be created on the server by an administrator, separate from this web application.

Default

This page simply contains all of the various documents that our team has created throughout the last two semesters. It also has links to code documentation for the microcontrollers and python application, and a link to the SVN repository at SourceForge.com. This page fulfills no functional requirements. It only provides information on the project.

Data

Here is where past gathered data can be viewed. After choosing a chamber, a data type, a time span, and a chart type, all data collected meeting those requirements is shown both graphically and in a grid. The graphical representation makes visualizing the chamber environment very easy. If more detail is desired, a user can look at the raw data in the grid

22

below the graph. For better browsing of the data, the grid also supports sorting and paging.

Settings

The Settings page is where current periodic tasks for each chamber can be viewed, along with chamber data samples at the time a chamber is selected. This is also where new tasks are added and deleted. After choosing a task type, a user can set its start time, a period if the task should be periodic, and any additional data required. Clicking the Add Task button will send the information to the Python server application to be added. Clicking the Delete button for any task in the table will delete that task.

Additional Functions

Initializing the users table in the database must be done via a separate utility. This should only ever be run when first setting up the server for this project. New users can be added by either modifying the SQL queries in this code, or by using a database viewer such as MySQL Workbench to add users to the users table.

Server User Interface

Also provided is a Command Line application, called CLIFE.py. This interface provides a simple interface to the chamber control program that runs on the same computer as the server. A web server and internet connection are not required to run CLIFE. Typing 'help' once CLIFE is started lists the available commands. Most of these are control commands, not data commands. CLIFE allows quick access directly to the server program, and is useful in many instances - especially debugging. CLIFE can be started in Windows by clicking 'CLIFE.bat' in the Server App directory. CLIFE has the same requirements to run as the Server program.

Central Server Program

23

The Central Server program is responsible for coordinating interactions between the user front end(s) and the growth chamber(s). All communication to and from the chambers is handled by the program. The program runs for the duration of the use of the chambers. The server must be able to receive commands from a variety of user interfaces. The program is able to communicate with any number of growth chambers. The program is responsible for obtaining and storing all sample data from the chambers in a central database.

The primary task of the server is to wait for tasks in the queue to become ready, and then to send them to the appropriate chamber. The other half of its operation is to listen for messages from the font-end that are then turned into tasks and placed in the queue. The queue is the mechanism by which the program regulates tasks in the system. The queue will be sorted based on the time that a task is supposed to be executed.

A task is any operation that requires interaction with the growth chambers. Examples include: turning the lights on and off, operating the sprayer pump and taking sensor readings. Operations are broken up this way for a number of reasons. The first reason is that it keeps the on-board microcontroller code very simple. Because the code on the micro-controller is much more difficult to change than the server program, the separation allows easier development and maintainability. The second reason is schedulability. Because the user should be able to schedule periodic tasks (e.g. water the plants every 20 minutes), and because the microcontroller has no real sense of time, it falls to the server program to coordinate these periodic tasks. A task always has a pre-defined result, whether it is that the pump turns on, or if recent samples are added to the database. In this

24

respect, testing is far easier to do because knowing if it worked is as simple as seeing if the desired change happened in the desired place.

The server program is broken into three major components: two dedicated to communication and one dedicated to scheduling. There is a module that handles messages to and from the chambers, one that listens for commands from a front end, and the scheduler receives and dispatches tasks accordingly. The server and chambers communicate via RS-232 serial protocol. The front ends send messages via local socket. The scheduler uses a priority queue and a real time clock to make its decisions.

The serial communication layer is a separate module within the server program. This allows us to run tests easily, and also make it possible to modify the means of communication between the server and the chamber.

The socket listener for the front-end is similarly modular to the serial communication layer. This layer simply sits and listens for incoming messages. When a message is received, it is translated to a task and placed on the queue, assuming no error has occurred. The use of sockets to receive messages from the front-end allows us to easily develop multiple front-ends. It also allows us to easily debug the system, by manually offering messages, and checking that they are placed in the queue and executed as expected. The socket listener provides no means of authentication – that is to be handled by the front-ends. However, the socket will be local to the server computer and thus only through one of the front-ends may an attacker attempt to alter the server program.

The format of messages between the server program and the front-ends is JSON. The JSON format was chosen for its simplicity and readily available libraries. Because the format is so simple, adding features such as new settings or parameters is straightforward. Using JSON also means that a front-end can be written in nearly any language, so adding a new front-end is as easy as possible.

The data format for communication between the server program and the microcontroller on the chamber is based on C structures. Two structures are defined, one for settings and one for samples. When ready to send data, the structures are serialized and sent in the order they are declared. This format is less agile and clear than JSON, but was much simpler to implement on the microcontroller.

The program includes logging capabilities that allow the user to view a history of all transactions. This helps in testing and debugging, but is also useful for the end user to verify that the schedule they created was followed. This data can be useful when compiling a research report.

25

The scheduler contains a single task priority queue, sorted by task start time. A queue is periodically polled for the next task. If the task is ready, then it is dispatched. If the task is not ready (and consequently, no other task is ready) then the task is placed back in the queue.

Both the server and the microcontroller have watchdog timers in place to timeout on serial messages. In the case of the server, the program abandons a communication if the chamber does not respond in 2 seconds. After this time, a new message may be sent. The microcontroller uses a hardware watchdog timer that is set for 64ms. Each time a message is received, the watchdog is started. If the processing does not reset the watchdog after 64ms, then the microcontroller is automatically reset. This feature ensures reliable communication with little human interaction.

Microcontroller

This is a graphical view of what the microcontroller software does. Most of the time the microcontroller sits in a sleeping/listening state waiting for an action to perform. The three main actions to carry out involve temperature, sound generation, and accessing sensors.

The temperature is set by the user and remains within plus-minus one degree of that setting. The way that this is accomplished is by having the microcontroller access the temperature sensor. When the temperature is found to be within the acceptable range, then nothing will happen. When it

26

is found to be below the low threshold the microcontroller will then turn on the heater. Once the temperature is back to the set temperature the heater will be shut off.

In order to keep the plants in the chamber alive, they receive nutrients from a bucket. To provide easier use to the operator, the level of this bucket is monitored. The bucket contains a float sensor that activates when the nutrient level reaches a certain point. When this point is reached an interrupt is generated on the microcontroller causing it send a message to the server that the nutrient solution needs to be replenished.

Our chamber is equipped with a speaker. A separate microcontroller uses an Analog Devices DDS to produce a random sound wave. The sound wave produced is random because every millisecond or so a new frequency between 1kHz and 20kHz will be selected. There is also the ability to control the volume of the sound. In order to turn the sound wave on/off, as well as set the volume, the user will use the web server to make their selections and then the web server will send a message to the microcontroller. The user is able to set the center frequency for the sound generator. This center frequency, fC, is used to set an upper, fU, and lower, fL, bound on what frequencies are randomly generated. The lower frequency is set at f L=0.707∗f Cand the upper frequency is set at f U=2∗f L. The length between new frequencies being selected is then based on a multiple of the period of the lowest frequency in order to allow at least one period at that frequency. Therefore: delay=1/ f L∗1.05 (s).

Since the microcontroller does not have direct access to a real time clock, the web server will be in charge of turning the light on/off, and initiating reads of the CO2, temperature, and humidity sensors. The web server can send a command to the microcontroller to read the sensors. When this message is received, the reads take place and then the results are sent back to the web server. The web server will also send a message to turn the light and pump on and off at the times requested by the user. There will also be commands for the web server to get the state of all components that are connected to the microcontroller. Finally, the user can use the web server to change the temperature settings and sound settings on the microcontroller.

Software Documentation

A large project such as this demands a good set of documentation, not only for current development but also for future maintainers. In order to organize and document our code and development, we have a number of tools in place.

27

Compiled Documentation

All the C code and all the Python code are fully documented. For C, we use Doxygen style comments and use Doxygen to build a fully searchable html page containing each function and field. The Python code uses pydoc style comments for each method and class, and this documentation is built with the epydoc program.

Source Version Control

Because keeping track of code changes, as well as making the code accessible to all team members, we chose to use the Subversion source control system (SVN). Subversion allows us to have a centralized code repository and a simple method for keeping track of changes to the code base. We have our repository hosted on SourceForge.net, a free project hosting site. The repo can be viewed at: http://sourceforge.net/projects/sdmay11-22code/

28

At the current time we have over 130 commits, here is a graph showing activity:

And a sample of our commit log:Revision: 81Author: creeve0514Date: 4:34:36 PM, Tuesday, April 12, 2011Message: fixed uptasks

Revision: 80Author: creeve0514Date: 6:05:44 PM, Monday, April 11, 2011Message: Pretty much done now.

Revision: 79Author: zdavkeosDate: 5:57:17 PM, Monday, April 11, 2011Message: Added some casts

Revision: 78Author: zdavkeosDate: 5:53:51 PM, Monday, April 11, 2011Message: Added debug print statements

Revision: 77Author: zdavkeosDate: 5:12:39 PM, Monday, April 11, 2011Message: Added code to fix unicode problem?

Revision: 76Author: zdavkeosDate: 5:04:04 PM, Monday, April 11, 2011Message: added unicode warning

29

Software Testing

With so many parts to the software system, it was very important to implement reliable communication mechanisms. With reliability comes thorough testing. In this respect we chose to do strategic unit testing on the communication modules. Ideally we would have unit tests in place for the entire system, but this was infeasible with such a large code base and such a tight schedule.

Strategic Unit Tests

There are two main points of communication: between the front-end and the server, and between the server and the chamber. We have implemented thorough unit tests for both of these points.

Serial Communication

For the microcontroller end, we have nearly 700 lines of C code that has 100% code coverage of the serial receive module. These unit tests test both positive and negative cases. A positive case is where the command or message is supposed to succeeded, a negative case is where the command is supposed to fail. By testing both positive and negative cases, we get a more thorough test – and better assurance of quality. Sample test run: Sample test code:

30

/* test implementations */

int test_light_on_mine(void){ uint8_t tst[] = {ADDR, 0x01};

current_test = __func__; count = 2; bs_error = 0; indx = 0; cmds = &tst[0]; switch_light_on_called = 0;

do_get_input(byte_sender);

if(bs_error == 0 && switch_light_on_called == 1)

return 0;

return -1;}

int test_light_on_other(void){ uint8_t tst[] = {ADDR-1, 0x01};

current_test = __func__; count = 2;...

Starting tests...test 0: test_light_on_minetest 1: test_light_on_othertest 2: test_light_off_minetest 3: test_light_off_othertest 4: test_pump_off_minetest 5: test_pump_off_othertest 6: test_pump_on_minetest 7: test_pump_on_othertest 8: test_heat_off_minetest 9: test_heat_off_othertest 10: test_heat_on_minetest 11: test_heat_on_othertest 12: test_sound_off_minetest 13: test_sound_off_othertest 14: test_sound_on_minetest 15: test_sound_on_othertest 16: test_set_sound_freq_minetest 17: test_set_sound_freq_othertest 18: test_set_sound_vol_minetest 19: test_set_sound_vol_othertest 20: test_get_samples_simpletest 21: test_get_samples_simpletest 22: test_get_state_simple_othertest 23: test_get_state_simple_otherCommand 'EE' not found.test 24: test_no_such_command

Tests Summary: Passes: 25, fails: 0, total: 25Whoohoo! No failures!

Socket Receive Protocol

Communication between the server and the front-ends is also crucial, so we have in place unit tests to ensure that incoming commands are handled correctly by the server, and the erroneous commands are discarded. For these unit tests, we used the built-in python module: uinittest. This module allows us to quickly and easily write unit test cased as we code the SocketReceive module. These tests test for erroneous and malformed messages that could destabilize the server, as well as testing to make sure legitimate messages are interpreted and dispatched correctly.

Electrical Design

Designing the electrical portion of the project was kept in mind from the very beginning. During the first semester we worked more on how things should theoretically work before starting in earnest on the design the second semester. From the first idea to the final product, there were many decisions and revisions to get to what we have now. We went back and forth many times on whether we should design a PCB or not. Eventually it was decided that even though doing a PCB would take a while, it would be worth it in the end. Below are descriptions of the major components on the electrical side.

Power

To supply the power needs for the IC logic for the chamber, a 12V wall wart was originally considered. With all that is going on though, there are five main voltages needed: 3.3V, 5V, 6V, 12V, and -12V. Needing voltage regulators for all of these, as well as, needing the current necessary to run everything, the wall wart was quickly discarded in favor of a standard ATX power supply. This delivers all of the voltages except for 6V, which is supplied from voltage regulators, with more than enough current. One problem with the -12V rail on the ATX supply is that it has a low current limit. The -12V is needed for the negative biasing on the op-amps for sound production. Needing a current upwards of 0.3A at this voltage and having that be near the limit of the ATX supply, a solution was needed. After a lot of searching, a part from TI was selected. The part, ptn78020a, is a negative inverting voltage regulator. This regulator can be set to output -12V and can supply up to 4A at its peak. With 25A available on the 12V rail, this part is more than sufficient for our needs.

The pump, light, and heater all run on 120VAC power. This presented a challenge of how to control them. The solution was a relay capable of handling up to 220VAC. This relay is then controlled with a 5V signal sent from the microcontroller.

31

Microcontroller

A microcontroller (MCU) is necessary to handle all of the tasks capable of being performed on the chamber. Originally, there was going to be one MCU carrying out all tasks, but this quickly proved unrealistic with all of the demands possible, especially for sound production. It was decided to go with 2 MCUs, one for sound and one for everything else. The main MCU is an Atmel Atmege328, and the sound one was going to be the TI MSP430. The MSP430 did not have enough input/output pins though, so it had to be swapped for the Atmega328 as well.

The main MCU has the responsibility of receiving and sending messages from the server. It accomplishes this via serial communication with the onboard XBee wireless component. The operation of the MCU software is explained in an earlier section of this paper, but to restate the MCU will get data from the sensors and pass it back to the server. It also controls the state of the relays and passes information necessary for sound production onto the sound MCU. The three sensors utilized in the chamber each have their own interface protocols. Communication with the temperature sensor is handled over I2C, while the humidity sensor uses one line for digital reads and writes, and finally the CO2 sensor is analog. PWM is used for the main MCU to send commands to the sound MCU.

Sensors

The three types of sensors for the chamber are temperature, humidity, and CO2. The temperature sensor is the TI TMP100, humidity is Aosong Electronics DHT22, and CO2 is Hanwei Electronics MG811. In order to get a temperature reading from the TMP100, address and command bytes are sent on the I2C bus. Once this data is sent, the sensor gets the latest temperature and sends it back to the MCU. The humidity sensor utilizes a single data line for digital communication. This line is held high when there is no communication taking place. When a new humidity reading is needed, the line is pulled low, by the MCU, for 1ms. After this, the MCU waits for the sensor to send back 40 bits, which includes the latest humidity reading. The CO2 sensor is an analog sensor. Its output is in the mV range, so a National Semiconductor LMC6035 op-amp was added to increase the voltage as well as stabilize the output. With the op-amp in place, the voltage is increased to the V range and is connected to an ADC input on the MCU. The MCU then reads the ADC to get the current value.

Sound

The sound generation has gone through three different renditions. Originally, the plan was to use PWM on a microcontroller to output a square wave at the specified frequency. The problem here is that PWM produces a

32

square wave that contains not only the desired frequency but many others. To get rid of the other frequencies was going to require a bank of band pass filters set to many different frequencies. The output from one filter would then be chosen based on the frequency that needed to be produced. After discussing this as a group, it was decided that this was not the best approach, so a new solution was needed.

The second attempt at sound generation was based on a Wien-Bridge oscillator. This oscillator produces a sine wave with amplitudes that can be adjusted by changing four resistors. The frequency is also adjustable by changing two resistors or two capacitors. With digital potentiometers readily available, this looked like a viable solution. A problem was discovered though, the sine wave produced by this oscillator is both positive and negative and the potentiometers can only handle positive voltages. The sine wave could not be made to be only positive, so yet another solution was needed.

Still wanting a sine wave, a search was made for a part that would have an all positive sine wave output, and the Analog Devices AD9835 was found. This is a digitally programmable sine wave generator. It outputs a wave from 0V up to 1.3V and can be programmed to within 1Hz accuracy. A SPI bus is used for the sound MCU to program the frequency into the generator, but the output signal still needs to be amplified to at least 90dB. To accomplish this there are two stages of amplifiers. The first amplifier is a non-inverting voltage amplifier, which uses the TI µa741 op-amp. A potentiometer is used here to allow the maximum amplitude to be increased by up to a factor of 6. This is used to increase the sound volume by 2dB. The second amplifier is again a non-inverting amplifier, but it is used for current amplification. The TI opa548 op-amp was chosen here because it has a controllable current limit. Since the first amplifier stage is used to control the volume, the second stage is set to always provide the same current. The current of 0.3A was selected by setting the first amplifier stage to have its least amount of voltage amplification, and then the current limit was changed on the second stage until a volume of at least 90dB was achieved.

Depth Sensor

We needed a depth sensor to notify the user if the nutrient solution gets too low. We considered using an infrared, and even a sonar sensor. As one of our main concerns for this design project was to keep the cost low, we quickly discarded the first two ideas. The third solution was to use a couple of

33

electrodes in the nutrient solution, which would conduct a current until the solution level got low enough to open the circuit. However, we realized we needed to closely maintain the pH and nutrient content of the solution, and the electrolysis might affect the solution composition. Finally, we decided to go with a simple mechanical float sensor, which would not tamper with the nutrient solution. The float sensor would complete a circuit when it got to a predetermined low level, thus sending a HIGH signal to the microprocessor. At all other times, the circuit would be open, sending a LOW signal to the microprocessor.

PCB Design

PCB

34

Schematic

35

Parts List

Name Value Manufacturer Part #C1-C2, C6-C8, C16 10μF N/A N/AC3-C4 22pF N/A N/AC9, C13, C15 100μF N/A N/AC10-C14 4.7μF N/A N/AConn1-3 N/A 3M 2510-6002UBCr1 8MHz N/A N/AR1, R4, R6 10kΩ N/A N/AR2-R3, R5 4.7kΩ N/A N/AR8-R9, R14 1kΩ N/A N/A

36

R7, R12 1MΩ N/A N/AR10 220kΩ N/A N/AR13 150kΩ N/A N/AJ1 N/A Molex Inc. 39-28-1243J2 N/A Molex Inc. 39-29-9042J3-J4 N/A Molex Inc. 26-60-4020J5 N/A N/A N/AU1, U15 N/A Atmel Atmega328U2 N/A Texas Instruments CD40109BU3 N/A Digi International XBee XB24-Z7WIT-004U4, U6 N/A ON Semiconductor MC7806CTGU5 N/A Microchip Technology MCP42100-I/PU7 N/A Texas Instruments μa741U8 N/A Aosong Electronics Co. DHT22U9 N/A Texas Instruments TMP100U10 N/A Hanwei Electronics Co. MG811U11 N/A Texas Instruments PTN78020AU12 N/A Texas Instruments OPA548TU13 N/A National Semiconductor LMC6035

37

Budget & Schedule

Budget

PricePurchased Parts

PCB $33 PCB Parts $165

Chamber Parts $290 Existing Parts

Pump $195 Light $105

Heater $20 Total $808

Schedule

38

References

Gladon, Richard. Associate Professor, Department of Horticulture, Iowa State University. Personal interview. 15 Sep. 2010.

Langhans,Roberts and Tibbitts,Theodore, eds. “Plant Growth Chamber Handbook.” Ames: Iowa State University, 1997.

39

Contact

Advisor

Timothy Bigelow2113 Coover HallAmes, IA 50011Phone: 515-294-4177Email: bigelow@iastate.edu

Students

Zachary Davis4700 Mortensen RdAmes IA, 50014Phone: 641-233-7209Email: zdavkeos@iastate.edu

Mohammed Rahim140 University Vlg Apt FAmes, IA 50010Phone: 515-572-4719Email: mrahim07@iastate.edu

Christopher Reeve530 Welch Ave Apt 1Ames, IA 50014Phone: 641-203-4794Email: creeve@iastate.edu

Daniel Wright2511 Bristol Drive #201Ames, IA 50010Phone: 515-401-2429Email: dwwright@iastate.edu

40

Appendix I – Sound Fourier Transform Captures

Constant Tone (1kHz)

Random Noise (1kHz Center Frequency)

41

Appendix II – Development Setup Instructions

Each of the three main components of the system has its own set of setup instructions.

Chamber

The chamber requires two programmed AVR microcontrollers. The code for these is in the ‘Microcontroller’ folder of the SVN directory. You will need WinAVR to compile and link the program. Also needed is Arduino, an IDE for compiling the .pde files used in the sound controller chip. Use an AVR programmer along with the programming board to put the main microcontroller code on the main AVR chip. Use an Arduino Dieciemela board to program the sound microcontroller.

Server App

Setting up the server computer requires a few prerequisites. See Appendix VI for details on packages required for running the server application. Once Python and all the prerequisites are installed, use ‘Run Server.bat’ in the Server App directory of the SVN repository. This will start the server. Any messages will be printed to the terminal window as well as written to server.log file in the src directory. To run the Command Line Interface program (CLIFE), use ‘Run CLIFE.bat’. This will start CLIFE. Type ‘help’ in the command window to see a list of commands to send to the server. Setting up pyMySql in Windows can be a bit tricky – consult the web.

Web Server

The web server requires Microsoft Visual Studio 2010. Before installing Visual Studio, ensure that Windows IIS is enabled in Windows services. You will also need .Net connector for MySQL server. Also needed is an installation of MySQL server configured and running. Consult the web for how to setup MySQL server. It is very helpful to have either Microsoft Access or MySQL Workbench installed for viewing database contents. Use Visual Studio to import the project from SVN repository. Select ‘Publish’ to deploy project to IIS web server.

42

Appendix III – User instructions

1. Start Server

2. Turn chamber on

3. Go to website and change settings as desired

4. Use website to view data and logs

5. Refill nutrient solution when advised

43

Appendix IV - Texas Instruments Parts

One of the objectives of designing our aeroponics chamber was to keep costs down as much as possible. This played a role in determining which parts we selected. The total price of what is listed below is about $55 and is 10% of the overall cost of our completed chamber.

CD40109B

This part is quite necessary for our project. On our PCB, we have some parts that run on 3.3V and some that run on 5V. For example, we have a microcontroller running at 3.3V, but it needs to control a relay that runs at a minimum of 5V. There are many solutions out there for converting between different logic levels, such as an opto-isolator, but this TI part was the simplest to implement. We are able to use one chip to control three separate relays as well as handle the communication between two microcontrollers running at different voltages.

OPA548T

The most important aspect of our project is having the capability to output random noise. Many of the parts that we have chosen from TI are directly related to this aspect of the design, and this part is one of them. The random noise that is generated must be output at 90-100dB. This is a substantial sound level and requires more current than a conventional op-amp could supply. Therefore, we needed a solution that could give us a higher current. For our purposes, we have setup the OPA548T to give us a current of 0.3A in a non-inverting amplifier situation. This amplifier works in conjunction with the μa741, described later, to give us the desired sound level.

PTN78020A

This is another part that is necessary for the sound portion of our project. We have a PC power supply that gives us all of the voltages needed. The problem is that the -12V rail on the power supply does not have enough current for the sound level required. The 12V supply has more than enough current, but there are not many solutions on the market that invert 12V to -12V except for the TI part listed here. The PTN78020A inverts that 12V input to -12V and outputs up to 4A, which is more than adequate for our needs.

TMP100

44

Part of designing an aeroponics chamber requires keeping track of certain environmental conditions. One of these is temperature. The TMP100 allows us to easily do this. With its I2C interface, it is simple to communicate with and setup.

a741μ

This is the second amplifier that is needed for outputting the random sound. The μa741 is a standard amplifier used in many situations, so it was ideal for us to use in a non-inverting voltage amplifier situation. We use the voltage amplification to control the volume of the generated sound.

45

Appendix V – Serial Command Protocol

Serial Communication Data Protocol

Table of Contents

1 Key 2 Protocol 3 Commands 4 TASK_GET_SAMPLES 5 TASK_UPDATE_SETTINGS

1 Key

→ == data sent from server to chambers

← == data send from chamber to server

2 Protocol

Server always initiates communication. Server gives exclusive access to channel based on chamber address.

1.) → address byte

2.) → command byte

3.) → any data bytes

4.) ← any return data

3 Commands

name number

bytes sent

bytes received

TASK_SET_LIGHT_ON 0x01 0 0

TASK_SET_LIGHT_OFF 0x02 0 0

TASK_SET_PUMP_ON 0x03 0 0

TASK_SET_PUMP_OFF 0x04 0 0

46

name number

bytes sent

bytes received

TASK_SET_HEAT_ON 0x05 0 0

TASK_SET_HEAT_OFF 0x06 0 0

TASK_SET_SOUND_ON 0x07 0 0

TASK_SET_SOUND_OFF 0x08 0 0

TASK_SET_SOUND_FREQ 0x09 4 0

TASK_SET_SOUND_VOL 0x0A 1 0

TASK_GET_SAMPLES 0x0B 1 2*ones(sent byte)

TASK_UPDATE_SETTINGS 0x0C 0 1

4 TASK_GET_SAMPLES

The server sends the 0x0B command followed by a single byte. The byte is a bit mask, where each bit corresponds to a physical sample. The bit mask is defined as follows:

bit Name description

0 Temperature

temp. inside the chamber

1 CO2 Carbon Dioxide reading

2 Humidity % rel. humidity

5 TASK_UPDATE_SETTINGS

When the server issues an 0x0C command, the

47

bit mask nam

e description

0 0b0001 Light Indicates whether light is on or

off

1 0b0010

Pump

Whether the water pump is on or off

2 0b0100 Heat Whether the heater coil is on or

off

3 0b1000

Water

A 1 indicates that the tank level is fine

chamber responds with a single byte. The byte is a bit mask where each bit represents a single state variable. The bit mask for the STATE byte is as follows:

HTML generated by org-mode 6.33x in emacs 23

48

Appendix VI - Python Dependencies

This is a list of all the non-default Python modules required to run the server app.

pyserial

sqlalchemy

MySQL

Json

49