You are at The Krib ->Plants ->Misc. Tech [E-mail]

Terrarium Control System

Contents:

  1. Terrarium Control System description
    by mark.stephens-at-gsfc.nasa.gov (mark stephens) (Fri, 27 May 1994)
  2. Terrarium Control System - download address
    by mark.stephens-at-gsfc.nasa.gov (mark stephens) (Thu, 02 Jun 1994)

Terrarium Control System description

by mark.stephens-at-gsfc.nasa.gov (mark stephens)
Date: Fri, 27 May 1994
Newsgroup: rec.aquaria,alt.aquaria,sci.aquaria,rec.pets.herp,sci.electronics,comp.robotics

Terrarium Control System (TCS)                      24 May 94

About a year and half ago a friend showed me his terrarium containing
plants and poison arrow frogs (gee, thanks Scott).  I was entranced... I
was in danger.  Hobby acquisition fever yet again swept over me and I had
to have one.  Except I know myself all too well.  Based on my tropical fish
experience, the terrarium had to be as automated as possible.   

Scott had a nice and attractive setup.  The terrarium is an aquarium turned
on its end, the open side sealed off with plexi.  Heat, supplied by a glass
denuded aquarium thermometer, was encased in PVC plumbing and delivered via
a DC fan.  It seemed to work quite well.  Scott also had some simple
circuits to run things (like a 555 timer to pulse width modulate (PWM) the
fan).  "Hey", sez I, "I can do that".

Little did I know that I was getting into electronics as a hobby.  I
discovered "The Art of Electronics" by Paul Horowitz and Winfield Hill and
never looked back.  (Whatever the hell that means, great book... a once in
a lifetime book.)  The original design that currently covers my breadboard,
was a combo analog and digital.  In the new design, all that remains of
this are the humidity sensors , temperature sensors and part of the fan
control ... and not a few brain cells of wisdom.  After having to deal with
comparators to try to turn on/off heaters and rain makers I realized that a
computer could make this soooo much easier.  Nothing a little C wouldn't
solve.  Based on "The Art", I designed a 68008 based system.  Then I
discovered the 68HC11 micro controller.  Sigh.  I mean, why have chips to
do A/D conversion, I/O and timing when its all in one neat package.  Back
to the drawing board.  This 68HC11 is done enough so that I hope to
breadboard the circuit and that's what I need you folks comments and
criticism on.

The circuit diagram was done on a Mac using Canvas.  This file and any
other format I can reasonably produce will be on cherupakha (thanks, Fred
Martin) in /pub/incoming/TCS.  There is a COMPRESSed postscript file
"TCS.ps.Z" and a native TCS.MacDraw (II actually).  I would be happy to try
and send another format, including the original Canvas version.  

Please note that I tried to follow standard symbols but boxes, pointy and
otherwise, refer to I/O on another page, not to edge connectors.  A
description of the system goals, the circuit and some questions follow.



         Goals
Grow orchids, bromeliads and frogs in a controlled environment simulating a
tropical rain forest.  No reason it shouldn't do for a desert, too.  The
maintenance should be minimal.  "Just add water" for the rain and food if
livestock is involved.  Heat, humidity, venting for fresh air, fan speed
and lights are all under programmatic control.  

The system is also a learning tool for electronics, micro controllers and
closed systems.  If there is to be a commercial aspect to this, the circuit
would be striped down to just what was needed to do the job.  And right at
the moment, I don't know what specifically is needed, so there are extra
stuff (do I really need four light controllers???, how do I keep time for
the scheduled events???).

Keep 'ol commercialism in mind.  This implies the least expensive route but
still maintain good quality.  Not that I intend to quit my government job,
mind you, but dreams are fun.



         Overview

At a minimum, a system for terrarium control needs to maintain temperature
and humidity and to turn on/off lights.  This can be done using a
relatively simple analog/digital system using op-amps, comparators and a
timer.  If the temperature is too low, turn on the heater.  If the humidity
is too low, turn on a rain pump.  Lights can be done via a common wall plug
timer.

A well rounded controller would do the above but also have venting to
supply fresh air and control of the fan speed.  Again, analog/digital might
suffice but the system could only be set up for single values (fan at 80%,
temperature at 85F, vent open 10 mins per day, etc.).  Adding the ability,
for example, to open the vents for a specified number of minutes per day
can be done, but you need lots of chips and somewhat tricky timing.  Add
things like temperature setback and scheduled events and you need a
microprocessor.  

The TCS is based around a 68HC11 8-bit micro controller which, depending on
species, has built in OTPROM, EEPROM, RAM (all 256 bytes), timers, A/D
converters, RS232 and four wire serial interface.  It can do a lot of
tricks.  The timer system has 16 bit timers and an I/O port which can
produce square waves or can detect edges, such as when a key is pressed. 
The address bus is 16 bits wide (68K of address space) and the data bus is
8.  That's in 'expanded' mode.  In single chip mode, it can use the built
in EEPROM and/or OTPROM to execute a program.  That's a future goal.  This
first version of the system will have the program burnt into ROM (choice of
battery backed RAM, EEPROM or OTPROM) and copied to RAM.  This allows the
program to use  static variables (talking the C language) and globals all
in one address space.  Seems easier for a beginner.  The CPU can be booted
in 'normal expanded' mode for normal operations or in 'bootstrap' mode when
talking to a computer like the Mac.  The memory map reflects this (see
diagram).  

The I/O portion of the circuit consists of the following memory mapped
devices selected by a 3-8 line decoder chip:  2 line x 16 char LCD,
momentary key input, 'on/off' devices, switches, LEDs and DIP switch.  The
'on/off' devices consist of a mister pump, rain pump, vent open solenoid,
vent closed solenoid (may be motors, TBD) and four lights (fluorescent). 
Fan and heater are pulse width modulated via the CPU timer ports.  Switches
are read for determining if the fan is enabled, if there is water for
rain/mist, if the vent is enabled and if the door is opened (don't want to
rain on humans).  The LCD, being a slow device, is connected to part of the
serial I/O port.  The rest of the port is used for RS232 communications,
when needed.

Humidity and temperature are the only inputs to the A/D converters (a total
of four on the chip being using).  The humidity is by Philips and it's
capacitance varies with humidity.  The circuit works by generating a
reference oscillation and then subtracting a similar oscillation produced
by the sensor.  The sensor oscillation will typically be shorter than the
reference one and the difference represents the humidity.  This is then
made (mostly) linear with voltage via a capacitor so that 90 mv implies 90%
RH.  Throw in a op-amp to expand this to 0-5 volts and you have something
the A/D converter can use (I hope!).  Temperature is even simpler as the IC
used produces a handy 10mv/deg F.  Again, an op-amp is used to expand to
0-5 volts.

The current design is purposely overblown.  The astute will note from the
diagram that the 3-8 decoder chip used for I/O could probably be done away
with as there are plenty of spare port pins.  There would be four more
added to the A/D port if the PLCC version of the chip were used.  There are
also some chips not on the schematic.  A calendar chip with battery backup
should probably be added (I will not produce a system that sez 'clock?'
every time the power goes off!).   But perhaps the 68HC11 can do the job.



         Software

Software is to be written in the C language as much as is possible. 
Currently, there is a core of code written in C and under simulation on a
Mac.  This is not a 68HC11 simulator, but one designed to test code dealing
with controlled devices, sensors and the end user interface.  A large part
of the code is involved in scheduling.  You can schedule anything under CPU
control.  If you want to create a rain storm every Saturday at 3pm, just
make is rain and turn up the fan.  

The current software is a simple loop.  Every 1/10th second, it wakes up to
do work.  It first gets the temperature and humidity from the A/D
converters.  Based on these values it determines if more humidity is needed
or if it's too hot (open vent) or too cold (turn on heat).  

Next a check is made to see if there is a scheduled event.  The system
holds an array of 50 events which can be associated with any device
controlled by the CPU.  I you want to turn on and off a light 50 times a
day, be my guest.   An event may be scheduled to a resolution of a minute. 
The event can occur every day or once a week.  For example, lights would be
set to turn on or off once every day while a 'rain storm' might be a once a
week affair.  If you want two rain events in a week, that would be a set of
two events.  The event array is time but not day of the week ordered so
that the software only has to look at events until it finds one in
scheduled for a future time.  A pointer will then be set to check that
event next.  Thus an event will only be done once.  Debugging this
subsystem is what make writing a simulator worth it!

Both events and the heat and humidity controllers can cause devices to turn
either on or off.  Turning on/off a device is done by setting/clearing a
bit in a byte.  At the end of the loop, this byte is written to the
'OnOffs' via the 3-8 decoder chip.

Heat and humidity are currently controlled with what I later found out to
be a simple proportional controller.  I've been plowing my way through
various micro processor controller texts and, while I've given up on fuzzy
logic for now, a proportional/integrating controller seems to be the way to
go.  

The LCD display is currently under investigation and has been prototyped in
SuperCard (a product like HyperCard).  Having only 2 lines of 16 chars.
apiece is very limiting.



Questions
1)  Can you PWM an AC powered device.  The heater will probably have steps
measured in seconds, but can you slow down an AC fan using a multiple PWM
step of 1/60th?

2)  The triac circuits look simple... too simple.  Are they going to work
for the somewhat nasty to handle fluorescent lights?

3)  What library functions can I readily adopt to this system?  Like RS232
drivers and LCD drivers.

4)  Is there a better way to use the A/D converter?  I'm taking the temp
and RH values from the sensors and expanding them to 0-5v.   The A/D
converter references 5v and ground.  Should I am for a lower reference of
2.5v from a low tempco voltage source?

Any help / comments / etc. would be most appreciated.

mark stephens

Terrarium Control System - download address

by mark.stephens-at-gsfc.nasa.gov (mark stephens)
Date: Thu, 02 Jun 1994
Newsgroup: rec.aquaria,rec.pets.herp,sci.electronics,comp.robitics

Ups, in the original post I did not use the complete address from which the
circuit diagrams can be downloaded.  It is 

            cherupakha.media.mit.edu 
login as    anonymous
file is in  /pub/incoming/TCS

Sorry about that.  If you do download, please let me know if there were any
problems as I really want folks to take a look!

thanks,

mark stephens


Up to Misc. Tech <- Plants <- The Krib This page was last updated 29 October 1998