AbstractThis document details the development of a

controlled growth chamber that can be used in a research

environment. The plants grown with this device are grown
consistently with the same light, temperature, and water level.
Additionally, this document also will detail the design, testing,
and further vision for this desktop farmer system.
I. INTRODUCTION
The aim of this project was to create a controlled growth
chamber that could be used in various botany and plant
biology laboratories throughout campus to aid consistent
growth of test specimens. Ideally, the chamber would grow
many plants, but for this prototype, a small number of plants
is being grown in the actual chamber. The ability to grow
organismsin this case, plantsin a controlled, consistent
manner is essential to research and there are few inexpensive
devices that allow the researcher to control numerous
elements of the growth process. Additionally, there is a
limited number of technologies that have a user interface
involving a web interface or an app interface and the
machines functionality. Both of these are problems that the
group aimed to address with this capstone project.
While there are growth chambers that provide researchers
the ability to control numerous aspects of the growth process,
these pieces of equipment are usually very expensive. One
major this goal for this AA/EE 449 capstone was to provide
the same functionality as an expensive growth chamber in a
cost-conscious manner. Another goal of this project was to
produce a system that was user-friendly, allowing the
researcher or operator to quickly and easily access
information about his or her system through a simple user
interface. Additionally, it was important that the user was
able to easily manipulate the environmental variables in the
system. This is where the problem of a unified user interface
for laboratory equipment arose.
When one thinks about a laboratory, there are many
pieces of equipment that are present in the room. Often these
machines are not only expensive, but they are also
complicated and rarely have the protocol to control the


C. Olson is with the Department of Electrical Engineering at the
University of Washington, Seattle, WA 98105 USA (phone: 253-670-4722;
e-mail: [email protected]).
P. Buckley, is with the Department of Electrical Engineering at the
University of Washington, Seattle, WA 98105, USA (e-mail:
[email protected]).
S. Makhsous is with the Department of Electrical Engineering at the
University of Washington, Seattle, WA 98105, USA (e-mail:
[email protected]).
A. Ravani is with the Department of Electrical Engineering at the
University of Washington, Seattle, WA 98105, USA (e-mail:
[email protected]).
operation of the machine. This makes it difficult to train new
undergraduate and graduate researchers as well as having the
potential to produce mistakes when working between a
number of different machines and to become an inefficient
use of a researchers time. This is where a unified user
interface with a protocol that interacts with numerous
machines in a laboratory setting would be useful. Tasks could
be monitored from a singular point and by removing human
interaction with the machine in monitoring conditions,
gathering information, etc. would thereby be able to reduce
the number of errors that may occur from, for example, an
incorrect button press. Additionally, if the equipment in
another room is also essential to an experiment, the
researcher could access the machine and its information
without ever having to go to the other lab.
While a number of growth chambers already exist and
there is little to be further explored, the area of developing a
singular user interface that interacts with a room (or multiple
rooms) full of equipment is an area that deserves further
scrutiny. It has the potential to reduce the amount of training
required for researchers, reduce the number of mistakes that
may occur by interacting with a piece of laboratory
equipment incorrectly, and allow researchers to use their time
in a more effective manner, focusing on their research and
not the machine they are utilizing to perform it.
The group completed the chamber within the budget
allotted for the class by the customer, so this goal was
achieved. However, the real contribution to the furthering of
technology is the emergence of this new idea and the partial
implementation the group attempted during this AA/EE 449
capstone project to interact with the growth chambers
sensors and control system. The protocol developed in this
project is fairly simple, but more elaborate interfaces can be
designed and implemented. In working with a piece of
equipment, a piece of technology in situ with the equipment
may be the most effective manner in which to implement this
interface; these could be linked together in one network and
as mentioned before, could be controlled from one webpage
or App.
This report will cover the problem the group is addressing
with the AA/EE 449 capstone project, the design the group
developed and what was implemented, the software that was
implemented to support the hardwares functionality, the
testing and verification of the systems functionality, and
finally, the results of the designs implementation and
discussion about design choices as well as any issues
encountered during the implementation of the projects
design. Overall, the implementation of the AA/EE 449
capstone was successful, but more could have been
implemented and developed with more time.
Baby Desktop Farmer
Desktop Controlled Growth Chamber
EE/AA 449 Final Report
C. Olson, P. Buckley, S. Makhsous and A. Ravani, Department of Electrical Engineering


II. PROBLEM DESCRIPTION AND PROJECT SPECIFICATION
While growth chambers and lab equipment exists to grow
microorganisms in a controlled manner, there is a distinct
lack of chambers available that give researchers the ability to
control an extensive number of elements in the organism
growth progress. Additionally, few chambers exist that are
capable of growing botanical organisms consistently while
giving their users extensive control over the growth process.
For instance, chambers exist that control light or control
temperature, humidity or water levels, or the nutrients and
moisture in the soil. However, few of these chambers give
users the ability to easily manipulate a large combination of
these elements. Thus, the group decided to design a system
that would fulfill this need for researchers both at the
University of Washington and elsewhere. Additionally, the
group decided to explore the concept of a virtual user
interface through either a website or an application for a
phone or other mobile device.
This section will discuss the problem the group addressed
in their AA/EE 449 control systems capstone. It will be
broken down into a description of where the group believed
their to be a need as well as discussing the specifications that
the systems design needed to meet. Due to this being a
system that is intended to grow botanical organisms
consistently, the requirements for the system are fairly
flexible
A. Problem Description
The problem this project addresses is a rather
straightforward problem. Researchers who study botany and
other related fields require that plants in their experiments be
grown as consistently as possible in order to form a baseline
upon which the effect of the manipulated variables will be
compared to. As stated before, few growth chambers exist
that give users flexibility to control an extensive range of
elements in the plant growth process. These can also be
fairly expensive. A low-cost, compact design for a
controlled growth chamber is an effective solution to this
problem.
The problem that the group originally addressed in this
AA/EE 449 capstone project, mentioned in the introduction,
is an inexpensive botanical organism growth chamber
capable of providing operators and researchers with the
capability to manipulate numerous of the same
environmental variables that larger, more expensive
chambers provide. However, an additional topic arose during
the development of the chambers design. This problem
addresses the numerous interfaces of laboratory equipment.
Different pieces of laboratory equipment have different
interfacesboth in operating system and operation structure.
Researchers have to walk to different machines (in the same
or different laboratories and rooms) to access the machines
information for their research. If the researcher desires to
change a variable in the system, the researcher must go to
the machine to change it. There are few virtual interfaces
that exist. A virtual interface for a piece of equipment
preferably multiple pieces of equipmentwill allow
researchers to perform their research in a more efficient and
timely manner, in addition to reducing the learning curve
when training new researchers and operators.
B. Project Specification
There were few strict specifications the customer
provided for the system. The specifications that the customer
did specify are included below as a list. Due to the systems
use in controlling the growth of plants, the response of the
system could be slow. Thus, there were no timing constraints
that the customer provided. For example, if the temperature
changed within a matter of hours, this was acceptable and
would likely not have an effect on the organism. A budget of
approximately $500 was provided to students to use in the
production of a prototype device.

Low cost ($500 or less)
Low power
Compact table-top design
Self-contained system
Simple user interface to control the chamber and
its systems
Temperature control to within of
specified temperature
Light exposure control (Red, Green, and Blue)
C. Project Success
To implement a successful AA/EE 449 capstone project
would be to implement a compact, self-contained system
that could be controlled from a computer-interface and be
capable of controlling at least temperature and the light that
the plants are exposed to. Additionally, the project would be
considered a success if the students implemented the design
within budget and on time. A successful demonstration of
this system would be to demonstrate that information can
successfully be accessed through the user interface, the
sensors are operating as expected, and finally, that the
operator is capable of manipulating these environmental
variables from the user interface.
III. SYSTEM DESIGN
This section will present the systems design to the reader
and discuss both hardware design and implementation, but
also software design and implementation. The intention of
this section is to provide a future student or researcher who
desires to further either the development of a desktop
botanical growth chamber or the development of the unified
user interface with information to being their project and
replicate the results from this capstone project.
A. Hardware Design Description
The hardware design of the Baby Desktop Farmer system
has two major segments: the mechanical implementation and
the electrical implementation. The goal of the hardware
design and implementation is to produce an enclosure that
meets all of the requirements for this project and to
eventually grow up to four plants in the chamber
simultaneously.


1) Mechanical Design
a) Enclosure Design
After conducting research, the group decided that using ABS
plastic to construct the enclosure would be the most effective
solution, both in effort and cost. The building process started
by using plastic as the only material for the enclosure. Inside
would be four holes in a tray to hold pots for the system. In
the below figures, the reader can see the initial design
models for the system. The material is a black ABS plastic
that is

thick. There are multiple levels to put the shelf unit

on, supported by plastic rails on the inside of the
chambers walls. On the back of the enclosure, there is a
diffuser meant to protect the plants from a direct flow of air
and also remove some of the heat from the system. This can
be seen in the second figure.


Figure 1 - The Front and Inside of the Baby Desktop Farmer Enclosure

Figure 2 - The Back View of the Baby Desktop Farmer Enclosure
Unfortunately, with the budget allotted to the group for this
project, this design was not feasible. To implement the only-
ABS plastic design, it would have been around $500 over
budget. In the second design, 80-20 aluminum was used as
the frame and the same ABS plastic was slid into the
aluminum and used as walls for the enclosure. In additional
to the original six sides of the chamber, another layer was
added behind the ABS plastic sheet at the front of the
enclosure. This layer was clear, allowing the researcher or
operator to view his or her specimens inside. Additionally,
this layer behind the opaque black ABS plastic allows the
view without changing any variables in the system such as
temperature.
Considering the systems water delivery system, a small
container was installed underneath of the holes for the pots.
This was done instead of making a fully waterproof
container and using the bottom. This can be seen in both
Figures 3 and 4.


Figure 3 Baby Desktop Farmer Enclosure with Clear ABS Plastic and
Opaque Black ABS Plastic shown on the Left and Right of the
Enclosure

Figure 4 Image showing the Bottom of the Baby Desktop Farmer
Enclosure. Heating and Water Delivery Systems are shown.
b) Controller Box
Building everything individually from different parts has
both advantages and disadvantages. One of the
disadvantages of having many different individual parts is

dealing with cable management and wire routing as well as
circuits in numerous places throughout the enclosure. This
can cause lengthy and complicated debugging. Additionally,
this can cause disconnections throughout the system if
cables and wires break unbeknownst to the operator. A
custom made controller box was the solution to this
problem. A 3D sketch and design were produced and then
inserted into a 3D printer to produce the part. This box can
be seen below as Figure 5.
The first (bottom) layer is intended to house all PCBs,
such as the LED controller, pump controller, and the heater
controller. The second (top) layer is designed to hold the
Arduino Mega microcontroller as well as giving the entire
box extra area for cable management and wire routing. The
lid covers the entire enclosure and provides protection for all
circuitry. It is mounted on the back of the enclosure.


Figure 5 3D Model for the Controller Box on the back of the Baby
Desktop Farmer Enclosure

Figure 6 Controller Box shown Mounted to the Back of the Baby
Desktop Farmer Enclosure
2) Electrical Design
a) Lighting System (LED Arrays)
Red, green, and blue LEDs were chosen as the lights for the
system. The customer discussed with the group the need for
these colors and they are common LED colors. In order to
implement the lighting system, the group chose to produce
LED arrays that would be set on top of the enclosure. After
measuring and calculating the requirements for the
maximum amount of light needed to grow, a design for a
four LED array system was developed. Four large PCB
boards were used to produce the LED arrays. The design
includes 288 LEDs total (red, green, and blue). The entire
system implemented operates on 12 V and 1.92 A of current
to produce the maximum brightness desired. These LEDs
can be seen during operation in Figure 7 and in schematic
form in Figure 8.
To control the brightness and power required to drive
these arrays, a 12 V, 6 A power supply with a custom
controller was implemented. The schematic for the
controller can be seen in Figure 10 and a photograph of the
controller can be seen in Figure 9.


Figure 7 LED Arrays While Operating


Figure 8 LED Array Schematic

Figure 9 Photograph of the LED Controller PCB

Figure 10 Schematic of the LED Controller Circuit
b) Water Delivery System
The original design for the water delivery system was to
split two containers and join them to produce the basin for
the water system. However, this leaked when implemented
and thus, one container was used. Additionally, the pump
was not bidirectional, so the system was implemented with
two pumps. The same power supply that provided power and
current to the LED controller and arrays was used to power
the water delivery systems controller and pumps. 5 V and
0.5 A was delivered to each pump through the use of a
voltage regulator (from 12 V input to 5 V output). In
addition to the container and controller, a water level sensor
was used to provide the operator with information about the
water level in the container. The sensor was larger desired,
providing for inaccurate readings, but a water level sensor is
required for the system to operate. Figure 11 shows the
schematic of the water delivery system controller.


Figure 11 Schematic of the Water Delivery Systems Controller
c) Heating System Design
The heating system was very basic. It was designed from
a high power resistor and used aluminum foil to dissipate
heat throughout the enclosure. The systems inputs were 12
V and 1.45 A from the systems power supply. Also, using
the temperature sensor, the heater could be controlled to
increase the temperature in the system or shut off to cool he

system. The temperature sensor uses I2C to communicate
with the Arduino Mega microcontroller. Figure 12 shows the
schematic for the circuit and Figure 13 shows an image of
the circuit.

Figure 12 - Heating System Controller Schematic

Figure 13 - Temperature Control Circuit
B. Software Design Description
Insert description of the software implemented in the
project (server and website) and describe why this software
implementation was decided upon. Discuss the controller
design.
The intention of the software design in this project is
aimed toward producing the automation of tasks the user
would perform; this task is done by abstracting system-level
controls away from the operator. To accomplish this, the
device is set up to read commands in the form of JSON
strings sent to and received from a server, accordingly.
Multiple devices can be attached and are identified through a
unique device ID hardcoded into the devices firmware. Two
types of commands are available for the Baby Desktop
Farmer device:

1. Get Requests: Requests that the device return a
state parameter such as the current temperature, the
desired water level, the current water level, etc. An
example of a get request is below:

{"cmd":"get","params": {"type":"temperature"}}

2. Set State: Sets a desired state for the device to be.
An example of a set request is:

{"cmd":"set","params":
{"type":"temperature",value:23.45}}

For the currently implemented device, getable states
include:
Current actual and desired temperature
Current actual and desired water level
Light intensity (for red, green, and blue LEDs)

For the currently implemented device, setable states
include:
Desired temperature for the enclosure
Desired water level
Light intensity (for red, green, and blue LEDs)

An overview of this relationship is outlined below.

Figure 14 Relationships for the Baby Desktop Farmers User
Interface
The operator only needs to interact with the device by
entering commands and checking device states online. This
does not include the setup. The currently implemented setup
includes plugging in the device into a PCs USB port and
running a Python script that acts as a relay for information
between the device and the server. Future implementations
would plug directly into an Ethernet port.

Further detail about the software implementation for this
projectthe devices software and the servers softwareis
included below.


3) Device Firmware

Scheduling of tasks for the device is accomplished through a
custom real-time kernel. Each task is responsible for
controlling the state of the device, measuring the state of the
device, or dealing with communication.
a) Temperature Control
This task runs at a time period of a minute, due to the slow
response of the systems heater. First, the temperature sensor
is polled and the current temperature is set. This value is
compared to the desired temperature and the error is added
to the integral of error, after which the error integral is
clipped to avoid any runaway responses. The error integral,
and the current temperature error are then used to compute a
control signal for the heating element, between 0 and 255
(the minimum and maximum PWM signals for the
Arduinos output pins). When the current temperature is
greater than the desired temperature, the heater is set to turn
off and the integral value is set to zero. The control diagram
is shown below.

Figure 15 PI Controller for the Baby Desktop Farmer System
This was the original design for the control system for
temperature; however, due to shipping issues with the heater
chosen for the system, a custom heater was developed for
the system. This heater, unfortunately, does not produce an
extensive amount of heat to change the temperature of the
system extensively. Due to the lack of heat in the system, the
integral term was invariably immediately saturated. In place
of the PI controller, a bang-bang controller was used instead,
as the resolution of the temperature always caused the
integral term to saturate. To demonstrate, if the temperature
was set to , and the current temperature was , it
took long enough for the chambers temperature to change
the small difference that the integral term would saturate as
there is no measurable values between the two values due to
the sensors resolution. Using only the proportional term
would cause a constant steady state error if it was low
enough not to saturate the controls when more than
approximately one degree of error was present. Hence, using
the bang-bang controller was a cleaner, more acceptable
decision, which can be though of as a proportional controller
with an infinite

and control saturation limits.

b) Water Level Control
The water level controller also used a bang-bang controller
during testing. When the water level was below the desired
level, one pump would turn on to add water to the system,
and if above the desired value, the pump that removed water
from the system would activate. However, during the
implementation, the water level sensor was found to be
extremely noisy when operating for the desired range. The
sensor is longer than the range of the water in the system is
high. (Ten inches versus approximately one to two inches,
respectively.) In place, a manual control system was used to
demonstrate the functionality of the system.
c) Communication
Before any command is received, the device polls the server
with a request for commands. This is in the form:

{"requestCommand":{"deviceID":DEVICE_ID}}

This is done every second. When incoming commands are
available, a response is sent from the server and the device
processes the command. If a set command is received, an
internal struct holding the devices desired state is updated
and the updated values are used during the next iteration of
temperature and water level controlling. If a get command
is received, the device writes a JSON string to the serial port
with the form:

{"deviceData":{"deviceID":DEVICE_ID,"type":"STATE_NA
ME","value":STATE_VALUE}}

The open-source aJSON library is used to encode and
decode JSON strings in the Arduino. While convenient,
there were some bugs that were the eventual downfall of
using the communication model outlined previously. Due to
some memory-management error, upon of the declaration of
a new variable in the aJSON object, the entire system failed
and the source of the error could not be resolved in time for
the final demonstration. A set of basic character commands
were used for the demonstration to control the chamber, but
the system was trivial and would not be used again. Future
implementations of this chamber should deal with the
memory issue and use the existing code base developed for
the Baby Desktop Farmer.
D. Parts List
The majority of the parts purchased for this project were
from SparkFun Electronics.

Table 1 Parts List for the Baby Desktop Farmer Prototype
Description Price ($) Quantity
100 Green LEDs 19.95 1
100 Red LEDs 19.95 1
100 Blue LEDs 19.95 1
Camera 49.95 1
1x5 Header Pins 1.50 2
Arduino Mega 58.95 1
SD Card 9.95 1
SD Shield 14.95 1

Temperature
Sensor
9.95 1
Light Sensor 1.50 1
Water Level
Sensor
39.95 1
Soil Moisture
Sensor
4.50 3
Barometric
Pressure Sensor
19.95 1

Humidity Sensor 9.95 1
Arduino AT
Mega Chip
5.50 2
IV. TESTING, VERIFICATION AND VALIDATION OF DESIGN
The testing for this system was fairly simple, as there are
no timing constraints impressed on the operation of the
chamber or on the operation of the software. Each piece of
the system operates on its own successfully.
A. Test Plan for the Chamber
All circuits were tested individually. For instance, each
LED array was tested with a power supply in EE137 and
then the controller was tested by using a 5 V power supply
and a 12 V power supply to provide the correct power and
control signals to the LEDs.
The heater circuit and the pump circuit were tested much
in the same way, with voltages being measured with a digital
multimeter. When each circuit was constructed, its
connections were tested for continuity before being tested
for operation.
As a system, the software was used to test the lights and
the overall integration of each of the pieces. If the lights
turned on, they were verified to operate as expected.
Similarly, if the pumps correctly added or removed water
from the system, the system was considered to work
correctly. Lastly, the heater system was tested such that if
the aluminum foil got warmer to the touch after being
commanded to warm the enclosure, the system was verified
to work as expected.
B. Test Plan for Software
The software was tested piecewise as it was being
developed. Slowly, pieces were added. When integrated,
commands were sent to the hardware and if the hardware
functioned as expected, the software was considered to
work.
V. DISCUSSION
The end result of the implementation of the Baby
Desktop Farmer project did not live up to expectations.
While it met the requirements specified by the customer, the
added functionality did not meet the groups expectations of
operation. The heating system, while slow, was not versatile.
The automatic water delivery system was not stable, but
partially functioned. Additionally, the camera was not
integrated due to the lack of time and the server
communication unexpectedly failed. These issues aside, the
system works and is capable of controlling all of the
elements the group sought to control and measure. The only
difference between what was implemented and what was
desired is that the system is manual instead of automatic.
The system is also very modular and each section had
differing successes and failures.
A. Heating System
The main issue regarding the heating system was the fact
that the heater did not ship for six weeks, in spite of
requesting one week shipping. Due to this, testing of the
heater was put off as it was always assumed that the heater
would be coming the next day. By the time the realization
was made that it was not coming in time, it was too late to
find an appropriate alternative. A homemade heater was
implemented instead, which did not provide the necessary
heat for accurate control.
Additionally, the temperature sensor did not end up being
accurate enough for a robust PI controller that could control
to the desired accuracy. This is addressed with more detail
in the software implementation section.
Repeating this project, the group would find a more
accurate temperature sensor and find a different heater, or
use the heater that came one day before the demo.
B. Water System
The water system used in this project relied heavily on the
accuracy of the water level sensor. However, the water level
sensor we purchased was much high less accurate than we
needed. The sensor is 10 inches long, and measuring a water
level of 0 to 2 inches, which is around the noise margin of
the device and ADC of the Arduino (the water sensor used a
logarithmic taper, so the top 2 inches dont change the
reading much, only around). The pumps used for the project
were perfect for the application, providing a low flow rate
and runnable off a simple 5V input.
The main way to improve the watering system would be
to find different sensors. One approach would be to use a
binary sensor using two wires to tell if the water is above a
certain level. This is not very flexible, however. Another
approach would be to find another, shorter sensor.
C. Camera
The original specifications the group decided on (based on
the requirements specified by the customer) did not include
the camera. However, the group acquired one regardless and
was able to make it function with the Arduino
microcontroller. Unfortunately, due to the time limitation the
group faced and an issue with the new Arduino IDE, the
camera was not integrated into the final system. The library
used for the camera requires an older version of the Arduino,
while the rest of the code was compiled with the newest
version.
D. Server Communication
This was one of the largest disappointments of the project.
As one of the more unique aspectsand an aspect that
addresses the unified user interface problemthe ability to
control and monitor the system using a web interface was
very interest and adaptable to other projects, but it did cause
the group problems and issues. A similar system was created

for CSE 477 by P.Buckley and the same code base was used
in the Baby Desktop Farmer. However, a software bug cause
the system to crash unexpectedly and could not be resolved
in time for the final demonstration of the system. The system
was capable of sending a command, but it failed after the
first. The issue was traced to a memory management issue
with declarations of variables and overwriting some variable
in the aJSON library. However, the solution was not found.
In place of a web service, all of which was functioning
until the time of the demonstration, a serial command was
used to show the systems operation. If given another
opportunity to do this project, or more time to work on it, the
group would patch the library or learn more about the issue
and attempt to avoid the bug entirely. Alternatively, a non-
JSON approach would have also worked. However, that
would have reduced the flexibility of the code. Other
languages such as XML do not have Arudino libraries.
E. Overall
The design and implementation process could have been
markedly improved by more time. By the time parts arrived
we were already 5 weeks into the quarter with not enough
time to test the parts, determine if they were bad, and order
new ones. The hardware of our project was much more
difficult to create than was originally thought, also. All
major parts in the end were custom made, from the heater, to
the lights, to the LED drivers, to the software for the
communication. Going back, our final project may have
benefited from using premade solutions for parts, but the
learning experience of making everything from scratch was
a learning experience that we believe is more important in
this case than the final product.
VI. CONCLUSION
The main goals of our project were to develop a piece of
lab equipment that had an extensible interface and to design
and implement a growth chamber. On the later goal we
succeeded in what we set out to do. Our chamber can
regulate conditions inside of the chamber, although not as
well as we had originally hoped. As for the extensible
interfacing system, we succeeded in designing the system
but failed to implement it for our device. Time ended up
being a major issue.
Looking forward, it would be interesting to polish the
implementation of the lab equipment protocol for our device
and extend it to other devices. Similarly, creating a couple
examples of user interfaces for the web service would better
help demonstrate its benefits. Additional changes could also
be made to the current system by replacing modules such as
the heater and temperature sensor with more effective
elements. The design also always for more sensor to easily
be developed and future implementation would do so.

APPENDIX
A. Source Code
Source code can be provided on command by contacting
one of the authors of this project. Included below are the
commands that currently work to control the system.
These were the commands used to demonstrate the
functionality during the final demonstration. Additionally,
the communication code has been included below.

1) Serial Commands
Commands (each string ended by \n)

First char Second char Third char Action
l u r Turns RED lights up
(+25/255)
- - g Turns GREEN lights up
(+25/255)
- - b Turns BLUE lights up
(+25/255)
- d r Turns RED lights down
(-25/255)
- - g Turns GREEN lights
down (-25/255)
- - b Turns BLUE lights
down (-25/255)

t u * Turns temperature up
one degree Celsius
- d * Turns temperature
down one degree Celsius

g t * Returns the
temperature
- d * Returns the currently
set desired temperature
- w * Returns the current
water level
- l r Returns the RED light
intensity
- l g Returns the GREEN
light intensity
- l b Returns the BLUE
light intensity

w u * Turns the desired
water level up
- d * Turns the desired
water level down
- i * Turns on the pump to
pump water in
- o * Turns on the pump to
pump water out
- s * Turns off the pumps
to pump water

2) Communication Code
Data from Arduino:
{"requestCommand":{"deviceID":1337}}

Data from server
{ "cmd": "get", "params": {"type":
"temperature"} }

Data from Arduino:
{"deviceData":{"deviceID":1337,"type":"temperatu
re","value":10.04000}}

Data from Arduino:
{"requestCommand":{"deviceID":1337}}

Data from server
{ "cmd": "get", "params": {"type":
"temperature"} }

!BREAKS!



ACKNOWLEDGMENT
The group would like to acknowledge the Nemhauser Lab
and Professor Klavins for the opportunity to work on this
project and the funding to do so. Additionally, the group
would like to acknowledge Paul Buckley for leveraging his
CSE 477 work with this project and using lessons learned to
further the success of the Baby Desktop Farmer.
REFERENCES
[1] (2011) Arduino JSON Library [Online]. Available:
http://interactive-matter.eu/how-to/ajson-arduino-json-library/
[2] P.Buckley. CSE 477 Capstone Project, 2012.