This paper will report on the past year's work on the development of the microcontroller design for the second Purdue University small self-contained payload. A first report on this effort was given at last year's conference by Ritter (1985). At that time, the project was still at the conceptual stage. Now a specific design has been set, prototyping has begun, and layout of the two-sided circuit board using CAD-techniques is nearing completion. A redesign of the overall concept of the circuit board was done to take advantage of the facilities available to students. An additional controller has been added to take large quantities of data concerning the shuttle environment during takeoff. The importance of setting a design time-line is discussed along with the electrical design considerations given to the controllers

Deckard, Todd W.

Weber, David M.

English

NASA Technical Reports Server

Nsr-2o321' i
Multipurpose Microcontroller Design for PUGAS II
David M. Weber and Todd W. Deckard
School of Electrical Engineering
Purdue University
West Lafayette, Indiana 47907
Abstract
This paper will report on the past year's work on the development of the
microcontroller design for the second Purdue University small self-contained
payload. A first report on this effort was given at last year's conference by
Ritter (1985). At that time, the project was still at the conceptual stage.
Now a specific design has been set, prototyping has begun, and layout of the
two-sided circuit board using CAD-techniques is nearing completion. A redesign
of the overall concept of the circuit board was done to take advantage of the
facilities available to students. An additional controller has been added to
take large quantities of data concerning the shuttle environment during takeoff.
The importance of setting a design time-line is discussed along with the electrical
design considerations given to the controllers.
INTRODUCTION
This canister is Purdue's second
venture with the Small Self-Contained
Payload (SSCP) program. Both canisters
will have in common the fact that they
were controlled by a microprocessor-
based electronics system. This is
common to many Shuttle canisters.
In our second design of a canister
controller, we have taken advantage
of new technologies available since
the first Purdue canister was designed,
and of new facilities provided for
the students on campus. Specifically,
the use of a low-power CMOS version
of the popular Intel 8085 micro-
processor, and a Computer-Aided-Design
(CAD) system belonging to the School
of Technology has greatly eased our
design process.
OVERVIEW
The experiments planned for
the payload include a particle detec-
tion block, a floppy disk block,
a foam metal furnace and a moisture
desorption chamber. Also, because
the canister support structure is
being built from a foam-resin compound,
it is being considered as an experi-
ment. Its physical response to the
actual lift-off vibration will be
recorded.
The first two experiments are
passive and will require no inflight
control. The desorption experiment
requires only the opening and closing
of a single valve. As support for
these three experiments, temperature
data will be taken from various parts
of the canister over the duration
of the-,time in space. This will
record any abnormal conditions that
135
https://ntrs.nasa.gov/search.jsp?R=19870010888 2020-03-20T11:19:55+00:00Z
i
i
-4
might affect the materials used.
It will also report on the efficiency
of the passive thermal control system,
which is based on a phase-charge
in a high heat capacity salt.
The foam metal furnace heating
procedure requires the most compli-
cated control. This experiment
consists of melting a sample of tin
and zinc carbonate. The zinc
carbonate will decompose into carbon
dioxide which will diffuse homo-
geneously through-out the sample
resulting in a new "alloy" with
desireable weight and strength quali-
ties for space construction. This
experiment will be tied to one of the
three relays under astronaut control.
They will activate this relay when
NASA can guarantee a 5-15 minute
period of no vibration (i.e., no
attitude control thrusts or orbital
manuvering). The experiment requires
both control actions to be taken and
data to be stored. The current to the
furnace must be regulated to melt the
sample as smoothly as possible. One
control line will turn the current on
or off. This will be cycled to provide
smooth temperature regulation. The
controller will monitor the output from
several temperature sensors to provide
a thermostatic control. The heating cycle
is not a simple on-off operation.
Rather, for the experiment to work
properly, the metal sample is brought
up to a pre-selected temperature, held
there for a few seconds and then allowed
to cool.
Data will be stored from the temp-
erature sensors for analysis later on
the ground. The data will be taken very
slowly prior to heating to establish
initial conditions. Then as the critical
heating point is reached, data will
be taken at a faster rate. As the
furnace cools, data will again be taken
at a slower rate. Data will also be
taken from a triaxial accelerometer
during the melting and cooling in case
the shuttle does experience some accel-
eration. This will be correlated with
any anomolies in the metal sample.
Collecting the structure data
has a requirement that increases the
difficulty of implementation: the system
must sense the time of lift-off without
any signal from the shuttle crew. The
most obvious indication of lift-off
is the sudden increase of vibration.
As this lift-off vibration is to be
used as the signaling factor, vibrations
from handling must be ignored by the
controller. This is a critical decision
for the hardware to make for if the
wrong decision is made as to the
validity of the collected data, the
experiment will be a failure.
DESIGN DEVELOPMENT
At the commencement of this design,
the following considerations were kept
in mind. A system is needed to provide
precise, reliable control of a variety
of experiments. This system must be
able to monitor the canister conditions,
make decisions and store data for
retrieval after the shuttle returns
to Earth. Because Purdue hopes to
continue its involvement with the SSCP
program, it would be desirable that
the final design could be easily adapted
to future needs. Time would be saved
if a system was designed using materials
with which students were already basic-
ally familiar. It was decided that
a single board micro-computer met the
above requirements in the best manner
when also considering space, weight,
and power.
Reliability was a major concern
in this decision. The use of a single
control system has the drawback that
one fault can jeopardize the entire
canister results. An initial choice
was made to have a controller for each
experiment with a master system guiding
them and watching for any malfunction.
This idea was dropped for two major
reasons. First, hardware interfacing
and software for the master controller
136
would be a monumental task to complete
and to guarantee to work under a
variety of conditions. Second, a fail-
ure in only the master system could
still accidentally shut down all of the
individual controllers. Our final de-
sign uses only the three independent
controllers, with one each for the
structure, furnace, and desorption
chamber. The desorption controller will
also take canister temperature data for
the duration of the flight. If one of
the controllers malfunctions, only part
of the canister's experiments will fail.
The controller taking the tempera-
ture data will run from five to seven
days. Even at the low levels of power
used by integrated circuits, over this
period of time the total is large.
Because batteries make up the majority
of the bulk of the canister's weight,
low power usage is a must. For this
reason it was decided to use CMOS inte-
grated circuits. Since the flight of
Purdue's first canister in 1983, a CMOS
version of Intel's 8085 microprocessor
and related family of circuits has been
introduced. In addition, Purdue
currently uses the 8085 for its intro-
ductory microprocessor course. Thus,
many of the students involved in the
controller hardware and software design
are already familiar with the 8085.
The basic design, shown schemati-
cally in Fig. l, includes the 8085, 8k
of ROM for the software, 8k of EEPROM
for data storage, an eight bit analog
to digital converter, a mc146818 real-
time clock for system timing and an 8155
which provides 256 bytes of RAM, a
timer, and three input/output ports.
External communication is done through
one of the ports on the 8155. Adding
a communications chip to the prototype
to ease the loading and debugging of
software was considered. However, it
was felt that the prototype should be
an exact duplicate of the final flight
hardware. In this way there would be
little doubt that the final version
would work.
Another of the ports of the 8155
is used as an internal control signal
generator. The EEPROM selected has
six modes of operation, including
various write and erase modes as well
as read. The select lines to choose
one of these states come from this
port. This eliminated the need for
complex decoding of address lines to
select the proper functions. This
produced the benefit of reducing the
random logic to a level where it can
be programmed on one Programmable-
Array-Logic chip instead of using
several generic chips. This reduces
power and space and increases reliabi-
lity.
The timer of the 8155 performs
a very important function as a "watch-
dog". The controller microprocessors
are exposed to a very rugged and un-
predictable environment. If the pro-
cessor were to "glitch",due to a
transient in the power supply or radia-
tion, its internal registers might be
altered. The processor might freeze
up, execute non-program data or do any
number of unpredictable actions. The
timer output is connected to one of
the interrupt pins of the 8085. The
software will be written in such a way
that when a procedure has been comple-
ted, a flag will be set and the pro-
cessor will pause. The timer will bring
the processor out of the pause and
check the flag. If the flag was set
then the software has probably been
running correctly. If the flag is not
set then the interrupt routine will
try to recover from the error.
It is felt that the only way to
insure that the returned data in memory
is valid is to keep a log record of
all actions taken in the EEPROM. If
power is removed or the controller stops
for some reason then it will be known
exactly where this occurred. The
watchdog routine will also use this
log to determine the status of the
system before an error occurred. The
log entries will include the time from
137
TC_J
r--
I
fn
i N
ORIGINAL PAGE IS
OF POOR QUALITY.
o
(:3
i--,.i
c/')
(.9
0-
0
_J
f---
0
c-
O
L)
0
0
%
4-)
0
4_
0
c-
O
or,,-
4-_
e_
q.J
(-
(.)
.r-
L 0 "" rn _ _ I_..................... J___................... 1........................
138
the real-time clock chip and a code for
the action completed.
The furnace and desorption con-
troller are identical. The structure
controller has been modified to perform
its special function. To study the
response of the structure to vibration,
Fourier analysis will be performed on
the data taken from strain gauges mount-
ed on the structure fins. This requires
that the sensors be sampled at least
8000 times per second. This is to avoid
problems in the analysis with high
frequency vibration. As sixteen chan-
nels are to be monitored, the resulting
128kHz sampling rate is beyond the
ability of the microprocessor and single
A/D converter system. An 8257 direct
memory access chip will be used to by-
pass the processor and directly transfer
data from a group of A/D converters to
a set of banked memory blocks. The huge
amount of data recorded will require
at least 128k of battery backed-up
memory. This memory will be selected
in 32k blocks by the same 8155 port that
controls the EEPROM.
Of great concern is the backing
up of the memory. EEPROM memory is too
slow to use fmr this application and
would require a large number of chips.
A combination of a battery and five
Farad capacitors will be used to backup
static memory chips. A very simple
analysis of the data will be done in
space and stored in the EEPROM so that
data will be retained if the memory
fails.
To activate the controller, a set
of vibration switches will trigger an
SCR switch. This device will latch
power to the controller until it is
shorted out under software control.
In series with the trigger switches is
a mercury switch. Because the canister
is stored vertically but launched al-
most horizontally, this switch will be
mounted at an angle that prevents
ground shocks from activating the
experiment. An additional safety meas-
ure will be a pressure gauge. This
gauge will be vented to the outside
of the canister. If the pressure drops,
then it will be assumed that the
shuttle is climbing into space. Once
the software has determined that good
data has been measured and has done
the preliminary analysis, the processor
will turn itself off permanently.
This will be done by blowing a small
fuse on the power supply line. In
this way this unit cannot be reactivated.
If the controller is activated acci-
dentally, it will temporarily shut
off by shorting the SCR. This will
break the connection. The controller
can still be reactivated by the next
shock.
The vibration experiment was orig-
inally designed as a separate circuit
board that would piggyback to a con-
troller identical to the others.
Through the use of the CAD system,
the design was stripped of the unneeded
slow A/D converter and the real-time
clock and condensed to one circuit
board. Because the CAD computer can
easily generate the modified circuit
board patterns, custom design of the
third controller was a practical con-
sideration. This would not be practi-
cal if the drawing was to be done by
hand.
All of the controllers will be
able to communicate to the outside
of the canister through the 8155 port.
This is essential so that the computer
hardware can be checked after it has
been installed into the NASA canister
at the launch site. The software will
include routines to check the hardware
and sensors. This will be done through
the use of an IBM PC as a terminal
for the controllers. The first action
a controller will take upon being acti-
vated will be to check a control line
to see if it is in space or on the
ground for testing.
139
PRESENT STATUS
Most of this design work was done
by the spring of 1986. Due to the fact
that this is a student project, there
is a continuous influx of new workers.
New members bring in new ideas and
methods of doing things. We found that
to keep the project moving at the
necessary pace, a date needed to be
set after which no changes would be
done to the design. Doing this gener-
ated the necessary activity to complete
the design. Setting such dates is im-
portant if work is to be completed.
Currently, we are in the process
of designing and choosing sensors, and
writing software. Because the control-
lers are essentially identical, most
of the software will be common to all
of them. This includes such routines
as the watchdog check, communications,
log updating, and system timing. Rules
are being generated for the code that
governs the unique operations of each
controller. These vary from being
simple for the desorption controller
to very complicated for the structure
experiment. A prototype has been built
and is being debugged. We hope to have
all of the controllers completed by
the end of the year.
ACKNOWLEDGEMENTS
The project team members would
like to thank Dr. Harold Ritchey for
donating the canister reservation to
Purdue and Dr. John Snow, our faculty
advisor, for his help and guidance.
Ms. Helen Henry assisted by typing this
manuscript.
140


Multipurpose microcontroller design for PUGAS 2

Abstract

Similar works

Full text

Available Versions

NASA Technical Reports Server