Download Display - Edge - Rochester Institute of Technology

Multi-Disciplinary Engineering Design Conference
Kate Gleason College of Engineering
Rochester Institute of Technology
Rochester, New York 14623
Project Number: P07103
INSTRUMENTATION PLATFORM FOR PROJECT
METEOR
Microsystems Engineering and Technology for the
Exploration of Outer Regions
Matthew Lipschutz /Electrical Engineering
Rashmi Shah /Electrical Engineering
Adam Gutterman /Electrical Engineering
Jessica DeSignor/Electrical Engineering
Peter Rozwood/Electrical Engineering
Rick Frisicano/Mechanical Engineering
ABSTRACT
A balloon-lofted observation and instrumentation platform was
created, tested and launched. The instrumentation platform was
able to retrieve data from a variety of onboard analog and
digital sensors, and compile the data into a cogent data packet
for transmission to the ground. The platform included multiple
video cameras and recorders, which documented different
views of the platform and the environment around it.
Telemetry data from the sensors was then overlaid onto video
stream and transmitted to ground.
INTRODUCTION
Meteor is a multi-year university-based project, which seeks to
launch small payloads into space on demand at a cost much less
than that of existing methods. The concept envisions an airlaunched rocket, raised up to its firing altitude by a highaltitude balloon. The instrumentation platform is meant to
attach to the balloon, documenting the launch of the rocket and
other relevant parameters. During the course of a six-month
senior design course sequence, an improved instrumentation
platform was designed, built, tested, and flown.
NOMENCLATURE
IP – Instrumentation Platform
XCVR – Transceiver
GCS – Ground Control Station
OSD – On Screen Display
V – Volts
A – Amperes
W – Watts
UART - Universal Asynchronous Receiver/Transmitter
ISR – Interrupt Subroutine
APRS - Automatic Packet Reporting System
ADC – Analog to Digital Conversion
I2C – Inter Integrated Circuit
GPS - Global Positioning System
JTAG – Joint Test Action Group Boundary Scan
TNC – Terminal Node Controller
GPIO – General Purpose Input Output
IC – Integrated Circuit
IF – Intermediate Frequency
RF – Radio Frequency
VGA – Variable Gain Amplifier
NTSC – National Television Standards Committee
ATV – Amateur Television
SPI – Serial Peripheral Interface
ESD – Electrostatic Discharge
HAM – Amateur Radio
BACKGROUND
Several iterations of the IP have been created during previous
senior design programs, with varying degrees of success. In
general, successive iterations added additional functionality
while reducing the size and weight of the platform. The team
worked on the previous year’s project in order to discover the
© 2007 Rochester Institute of Technology
Proceedings of the Multi-Disciplinary Engineering Design Conference
Page 2
constraints of the design and possible improvements [1]. After
a successful launch of the existing IP, observations were made
regarding possible improvements. Based on these observations
and specifications provided, decisions were made as to how the
new should be designed.
still/video cameras to document the flight, and a radio
connected to the radio communication board to transmit and
receive data and relay commands from the GCS.
The IP is meant to ascend to an altitude of approximately
100,000 feet. At this altitude, the system will be subjected to
random bit errors induced by cosmic radiation that would
normally be filtered out by the earth’s atmosphere. The system
needs to be designed so that it is tolerant to these errors.
Research was done to address this issue by the previous
instrumentation platform team. After considering all of the
options, it was concluded that the costs of error-resistant
hardware were greater than the potential benefits; hence none
of these options has been implemented at hardware level.
Redundancy was added in the software to ensure that the
collected data was valid.
A power analysis if the existing IP showed that the largest
consumer of power was the 70cm video transmitter. The new
specifications required a 5-fold increase in the power output of
the video transmitter, with a similar expected increase in power
consumption. The main objective of the power system was to
provide power for the entire platform without increasing the
number of batteries required. To do this the efficiency of the
voltage regulators was targeted. The required rails were 5, 3.3,
-12, and +12 volts, with the video transmitter on the +12 Volt
rail. The other goal of the power system was to provide the
necessary voltage and power from only 10 9-Volt batteries with
sets of 2 in series to provide 18 V. This required very efficient
voltage regulators which must handle a range of input voltage
that spanned from 12V to 18 V (to include the drop in voltage
as the batteries ran out of stored energy).
DESIGN PROCESS
Early in the design process, the IP system was broken down
into major subsystems based on the specifications provided.
Each subsystem was assigned to an individual student, with
other students contributing to the design as needed.
Specifications
The major subsystems were:
 Power Board for all the power requirements: The new
power board was designed to increase efficiency on
each of the power rails.
 On Board Controller for data acquisition and platform
control: The microcontroller was changed from a PIC
[2] to an MSP430. The sensors were changed to
produce more accurate results with less support
hardware.
 2m Radio Modem and XCVR for communication with
GCS: Replacement of existing data radio system
increased performance, reduced cost, and greater
reliability.
 70cm 5-W Video Transmitter: Increase the power of
the 70cm video transmitter for more reliable reception
at greater further distances from the GCS.
 Redesign of the OSD System: New OSD system was a
custom design for better adaptation to the needs of the
IP.
 Thermal Analysis: Create a transient thermal model of
the instrumentation platform as it ascends and
descends with a fill-in Graphic User Interface.
Final Design
The proposed design of the 2007 METEOR IP Team consists
of a platform with different electrical boards for on-board
controller, power, OSD and video mux, radio communication
and video transmission. There are two standalone digital
Power
The new design incorporated switching regulators which were
rated at 80-95% efficiency. The new voltage rails were 12V at
3 A, 5 V at 1 A, 3.3 V at 1 A, and -12 V at 50 mA. The first
three regulators were running directly off the 18 V battery
supply and the -12 required a 12 volt input so it would be
running off the 12 Volt rail. The 12 Volt rail was the most
efficient. The efficiency of the 12 volt rail was a key concern
because of the large amount of power required by the video
transmitter. Excess heat generation was a concern during the
design of the power system, though the thermal analysis
predicted that the platform would not have enough heat to keep
the system within operating temperature; therefore, any excess
heat generated by the power system and batteries would
actually have a positive welcome.
On Board Controller
One the major changes at the microcontroller level was the
decision to replace the existing Microchip PIC microcontroller
with a Texas Instruments MSP430. Using the MSP430 had
many advantages: source and destination addressing modes are
encoded within the op code, which yield dense code; and
internal memory is accessible at both the word and byte level.
The flowchart of the software for on-board controller is shown
in figure 1.
Interrupt Subroutines: The IP controller needed to be able to
implement two special functions regardless of its current mode
of operation. These two critical functions were:

Process a command sent by GCS

Send an APRS packet to modem at regular intervals.
One method of doing this was entailed simply adding these two
functions in a loop and processing it with the other functions
performed. This does not adequately represent the importance
of these functions. Hence, the alternate method of interrupt
Paper Number P07103
Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference
subroutines was chosen in order to execute the desired

functionality. A UART was dedicated for this cause in order to
ensure that it was monitored continuously so that none of the

commands would get dropped and
remain unprocessed.
Flow-Chart
of the Controller

Power Up Reset
$VCAMA – Choose camera channel 1

$VCAMD – Choose camera channel 4

$VROLL – Automatic Roll of video cameras

$VTOFF – Turn Video Transmitter Off

$VTXON – Turn Video Transmitter On
Initialization
Get GPS
Get Heading
$VCAMB – Choose camera channel 2
$VCAMC – Choose camera channel 3
Get Pressure
(1 Pressure Sensor)
Command Mode
Interrupt
Subroutine
Get Temperatures
(2 External, 2 internal)
Disable Other
Interrupts
Get Humidity
The transmission of an APRS packet at a regular interval was
important for0 consistency in data acquisition. This was
implemented with an interrupt timer which sent data to the
modem if a full minute had passed since the last transmission.
Valid Command?
1
Get Acceleration
Increment Counts
Execute
Command
1
0
Altitude
< Threshold
Turn Video
Transmitter OFF if
ON
Turn Video
Transmitter
ON If OFF
ow-Chart of the Controller
11
0
Video Camera
Count Done?
Reset
Roll Video
Camera
on
S
Sensors: The sensors chosen for this design used digital signal
transmission. Observations of the results from previous years
showed that if a precise voltage references are not provided, the
Reset Command
ADC conversion of the analog signal voltage used to transmit
Counters
the data was incorrect and yielded inaccurate data. The
MSP430,
Enable Other however, had an internal reference voltage, which
Interrupts
was
effectively used to implement desired conversion
reti
accurately
for components for which purely digital alternatives
APRS Packet
were notSend
available.
interrupt
Send Notification
Service Routine
ng
ure
ensor)
Command Mode
Interrupt
Subroutine
atures
nternal)
Disable Other
Interrupts
The digital sensors were I2C-compatible, which greatly
Time> 1 min since Last
reduced
the load on the microprocessor. Each of these sensors
Transmission
1
had a unique address0 on the I2C bus. The I2C-compatible
sensors that were available and implemented were temperature
Send APRS
and accelerometers. I2C-compatible thermistors and
Packetsensors
to TNC
pressure sensors were not found, so these sensors used analog
Reset Timer
inputs. There were two pressure sensors on-board for better
coverage of the range of expected pressures; no one pressure
reti
sensor was able
to accurately characterize the range of expected
pressures up to the maximum expected altitude of the IP.
dity
Valid Command?
0
1
ation
ounts
Execute
Command
0
old
mera
one?
Page 3
Turn Video
Transmitter
ON If OFF
Send Notification
Reset Command
Counters
0
Enable Other
Interrupts
reti
APRS Packet
Send interrupt
Service Routine
1
Time> 1 min since Last
Transmission
0
Send APRS
Packet to TNC
Reset Timer
reti
Rashmi Shah
Rev. 2 11/02/2006
Figure 1: Flowchart of the Controller
Whenever a command was sent, the controller generated an
interrupt and entered an ISR which performed the desired
action. Some of the important commands which were
implemented in this ISR were:
Crystal, GPS, OSD Data
and Shah
JTAG: The internal clock of the
Rashmi
Rev. 2 controlled
11/02/2006
microcontroller, digitally
oscillator is an integrated
ring oscillator with RC-type characteristics. As with any RCtype oscillator, frequency varies with temperature, voltage, and
device to device; as the IP scenario required vast fluctuations in
temperature, the digitally controlled oscillator was not
adequately reliable. External crystals were provided to provide
precise frequency. There were two crystals: 32.768 KHz for
use when the microcontroller was in low power mode, and 6.5
MHz for high speed mode. The GPS outputs data at a rate of
4800 baud which is received by the UART0; UART0 transmits
data to OSD at the same rate. The programming was done
through JTAG which was desirable because it provided incircuit debugging.
2m Data Radio Transmission
The data communication subsystem was the primary means of
ground-to–platform control and the backup telemetry downlink.
Copyright © 2007 by Rochester Institute of Technology
Proceedings of the Multi-Disciplinary Engineering Design Conference
Previous launches of the METEOR instrumentation platform
used the APRS, a widely implemented protocol for
broadcasting position data (typically directly from a GPS) over
the air via Amateur Radio and reporting this data on the
Internet. The open protocols used allowed Amateur Radio
operators to follow our launch and assist with recovery using
commonly available radio equipment. The results of previous
launches showed that while the infrastructure of the tracking
system generally reliable and versatile; the onboard XCVR was
unreliable at high altitude.
With this in mind, the
communication subsystem was redesigned to use a more
modular architecture and allow new uses for the system. The
block diagram for 2-m radio communication system is shown in
figure 2.
The XCVR used in previous launches featured an integrated
TNC. This integrated TNC used a Bell 202-compatible
protocol for the audio layer and the AX.25 protocol for the data
link layer. The new system separated the TNC and modem
functions from the XCVR. The XCVR itself was a Yaesu VX170, a rugged handheld radio suited for our purposes. The
radio was capable of the required 5W power output, and was
water-resistant for use in uncertain atmospheric conditions. The
radio was equipped with a Li-Ion battery, which provided more
energy storage and less mass than the Ni-Cd cells used on the
previous XCVR.
TinyTrak
SMT
TS3A5018
Switch
GPS
MX614
MSP430
Mode Select
VX-170 XCVR
Figure 2: 2m Radio Communication System
A separate circuit was needed to replicate the modem and TNC
functionality. Modem functions were handled by an MX614
Bell 202-compatible modem chip. This chip converted audio
tones to digital data. TNC functions were meant to be handled
by the MSP, but implementation of the AX.25 protocol was not
completed in the provided time frame. As a result, a vastly
simplified protocol was used, capable of only sending and
receiving strings of text, without provision for data routing,
error checking or other more advanced functions.
This limited functionality would render use of the APRS
impossible. To remedy this, a Byonics TinyTrak SMT was
added to the system. The TinyTrak was capable of transmitting
(but not receiving) APRS data using the AX.25 protocol using
an integrated TNC and modem. A GlobalSat EM-408 GPS
receive board was connected to the TinyTrak to provide
accurate position reports.
Since both the TinyTrak and the MX614 needed dedicated
access to the XCVR, a TS3A5018 audio switch was inserted to
Page 4
alternate access between the two devices.
Mode-select
functionality was provided by a dedicated GPIO pin on the
MSP. As configured, the TinyTrak broadcasted a position
report every 30 seconds. The MSP430 was set to give transmit
access to the TinyTrak for the majority of the time; when the
MSP had a telemetry packet ready to send, transmit access was
temporarily routed to it. Receive signals from the ground were
routed to the MSP at all times, so that it could consistently
receive commands.
Video Transmission
The function of the video subsystem was to transmit the video
signal from the IP to the receiving network on the GCS. The
video subsystem was critical; it was the primary means of data
downlink during the majority of the flight. Also, it provided
with a means to view the satellite which hung below the
platform. The goal of the video subsystem redesign was to
increase the range where signal was received up to 100 miles.
In order to accomplish this, a power amplifier module was
added to the design to raise the output power of the system 5W.
Also, the video subsystem was able to be turned on and off by
the microprocessor so that it did not interfere with the satellite
team’s communication. Hence, an input bit to the transmitter
was used to shut it down and turn it back on when needed.
The transmitter designed for this project is based on the Maxim
MAX2370 Evaluation Kit. The MAX2370 is a 450 MHz band
Quadrature Transmitter which takes a differential I/Q baseband
input and converts it up to an intermediate frequency through a
quadrature modulator and IF VGA. The signal is sent through
an IF filter and then up-converted to RF through an imagereject mixer and RF VGA. The signal is sent through an RF
filter and finally amplified by an on-chip power amplifier
driver. Once the MAX2370 was working, modifications were
made to the baseline design to customize it to the IP’s needs,
including frequency tuning to bring the tuned frequency down
from 450MHz to 439.25MHz.
Design constraints for the Video Subsystem included power,
heat, size, and RF layout restrictions. In order to achieve the
5W of output power, the Mitsubishi RA07H4047M RF
MOSFET Module was used. This module is specified at 2A of
current draw, which is very high compared to the rest of the
subsystems. Also, this module got very hot which affected the
thermal dynamics of the model. Thus, a heat sink was used. In
addition, the box designed to enclose all the printed circuit
boards, batteries, cameras, and radio has a design constraint of
8” x 6” x 4.” Consequently, the heat sink for this amplifier had
to be kept small. Furthermore, due to RF restrictions, layout
traces were kept as short as possible, trace impedances were
kept as close to 50 ohms as possible and impedance-matched
SMA connectors had to be used to connect the video in and
video out.
OSD
The METEOR IP contained four cameras which output an
NTSC video signal to remotely monitor the status of the
platform. An integrated IC, the LT 1204, was utilized to
Paper Number P07103
Page 5
Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference
multiplex the video feed between the cameras. The video
multiplexer takes its input from the main processor, which can
be set to scroll through a timed loop of each camera, or
controlled via uplink to select certain cameras for more direct
observation.
The output of the video multiplexer is then
passed to the OSD as shown in figure 3.
Digital Select Signals (2)
Infinite wait
loop
Hsync
detected?
Yes
Increment
line counter
No
Video
Multiplexer
(LT1204)
Port 1
Interrupt
Service
Routine
NTSC
Call Draw()
Yes
Camera 4
B/W
Timer
Interrupt
Service
Routine
Communication
Requested?
Figure 3: Video Multiplexer Flowchart
The OSD was an integral component of the data platform.
While sensor data was transmitted on the amateur radio band to
general receivers in the launch area, the video signal is
broadcast on an ATV frequency, where standard television
tuners can receive the signal. The OSD took in serial data from
the main microprocessor and overlays this data on to the
transmitted video signal. This form of sensor data acquisition
can be used as a redundant form of communication in the event
of interference or ground-control malfunction, where any
analog television tuner can be used as a receiver.
The OSD consisted of two integrated circuits, an
MSP430F2013 microprocessor and an EL4581 sync generator.
The EL4581 provided the detection of both the horizontal and
vertical synchronization signals used in the NTSC video
standard; the MSP430 then read the sync pulses and output
accordingly. A precision resistor and decoupling capacitor
were the only external hardware elements necessary to
complete the OSD circuit.
While the programming of the OSD and the associated
hardware seem simple as shown in figure 4, the stringent
requirements for video generation created design challenges.
While the maximum rated frequency of the microprocessor
used was 16MHz, the clock jitter at that frequency was rated at
Reset line
counter to
zero
Vsync
detected?
No
Camera 2
B/W
Camera 3
NTSC
Color
NTSC
Output
NTSC
Intiailize
Disable
Timer
Enable Port
1 interrupts
Clear Timer
interrupt flag
Yes
Disable Port
1 Interrupts
No
Camera 1
NTSC
Color
+- 1%, far exceeding the tolerance of the NTSC video standard.
Additionally, while theoretically the 16MHz processor should
be able to at the maximum clock frequency, GPIO pins were
simply not designed to switch this fast. To mitigate this
problem, SPI, normally used for communications, was used to
output digital signals and generate the character bit stream.
Call
Receive()
Set Failsafe
Timer
Clear
Interrupt flag
Figure 4: Main OSD program flow
The utilization of the SPI system for video generation created a
secondary challenge for the OSD to function properly; serial
communication had to be implemented using the GPIO pins. A
very simple bit-wise synchronous serial transmit and receive
subroutine was developed (shown in Figure 5) to be run on the
OSD microprocessor. The main microprocessor used to collect
sensor data was equipped with a similar transmit subroutine.
Copyright © 2007 by Rochester Institute of Technology
Page 6
Proceedings of the Multi-Disciplinary Engineering Design Conference
Receive()
Draw()
Loop for 21
characters
No
Is line between
220 and 230?
Yes
Clear temp
Calculate
Character
pointer [LT] to
determine
bitstream
output per line
Loop for 8
bits
Output
bitstream of
character n
from receive
string
Return to
Interrupt
Service Routine
Wait for
Clock pin
High
Bit Shift
Temp right
by one
20°C to -60°C. This was a potential problem for temperaturesensitive electronics: as a rule most parts were only rated down
to -40°C. For the remainder of the rise to an altitude of 25km,
the platform traveled through the stratosphere. Here the air
temperature gradually increased to approximately -50°C due to
the absorption of ultraviolet radiation [3]. A preliminary
transient thermal analysis was performed in ANSYS 10.0 using
a simplified model and a constant estimated speed of 16km/h.
This results in a time of ascent of 1.5 hours. Radiation was
neglected. See graph in figure 6 for properties used [4,5,6,7,8].
Thermal Simulation Parameters
40
20
Air Density (kg/m^3)
*10^-1
10
Int Convection
Coefficient (W/°C*m^2)
0
-10
Is Data pin
high?
Ambient Temperature
(°C)
30
0
20000
40000
60000
80000
-20
Air Conductivity
(W/m*K) *10^-3
-30
Air Specific Heat
(J/kg*K) *10^2
Air CTE (1/°C) *10^-6
-40
Write One to
Temp
Ext Convection
Coefficient (W/°C*m^2)
-50
Int Heat Generation
(W/m^3)
-60
Elevation (ft)
Wait for
Clock pin
Low
End 8 bit
loop
Write
character to
RAM
End 21
character
loop
Figure 5: OSD Subroutines
Thermal Analysis
The METEOR IP’s environment changed significantly as it was
lifted to its maximum altitude. The pressure dropped from
approximately 760 mmHg to 21 mmHg, and the density of air
decreased from around 1.2 kg/m3 to 0.045 kg/m3 [3]. The
changing convection and conduction coefficients of air affected
the thermal behavior of the electronics platform. The first 5 to 9
miles of vertical ascent is through a portion of the atmosphere
called the troposphere. Almost all weather occurs in this
region. The air temperature in this region falls from about
Figure 6: Thermal Simulation Parameters
The thermal model was set up in ANSYS 10.0 with certain
properties as parameters, some of which are variable and some
are constant. The internal heat generation was modeled as one
bulk constant estimated at 30 W/m3. The density, thermal
conductivity, specific heat, internal and external convection
coefficients of air were modeled as variable parameters. These
particular properties have a significant effect on the thermal
behavior and can vary greatly. Set up as parameters, the
properties can be easily changed allowing for numerous
simulations to be investigated.
With the initial set of parameters, the results predict that the
electronics did not dissipate enough heat to keep the IP’s
internal temperature in a safe operating range. The internal
temperature drops below -40°C at an altitude of approximately
13km.
PCB Block Diagram and Final Model
The integration of all the components created the final IP. The
block diagram for the IP is shown in figure 7 and final
assembly is shown in figure 8.
Paper Number P07103
Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference
Batteries
Power
Distribution
GPS
Sensor Data
Cameras
Main
Processor
TinyTrak
Video Multiplexer/
Text Overlay
Modem
70cm
Transmitter
2m
Radio
Antenna
Figure 7: Final Assembly Block Diagram
Figure 8: Final Assembly
PROTPTYPE TESTING
Each subsystem was thoroughly tested individually and in
combination with other boards before integration and final
testing.
Results
Numerous issues arose during testing, each of which was
thoroughly troubleshooted and resolved to the maximum extent
possible.
The power system ran as projected during ground testing and
validation. The 3.3, 5, and +12 voltage rails were within 1/100
volts of accuracy and the –12 was within .5 volts of accuracy.
Page 7
The minor difference on the –12 voltage rail was within the
acceptable tolerance for the components that were run off of it.
Some improvements that could have been made by adding
power switches so that the regulators could be turned on and off
while the batteries were still being attached. A –12V voltage
regulator that can run off of +18V instead of +12V and can
power exactly –12V instead of the achieved –11.5V would
have been desirable. Additionally a standardized set of
mounting holes near each corner of the board for attachment to
the case or other boards would have been desirable. Other than
some minor issues, the power system ran as expected.
Most of the sensors worked as projected. The I2C-compatible
temperature sensors, however, failed at an alarming rate due to
ESD, so analog temperature sensors were substituded.
The MX614 modem output digital data all of the time, even
when it was not receiving any valid data on the audio stream.
The MSP430's interrupt, however, was being triggered every
time this invalid data was received. The problem was solved
by checking the status of the MX614's receive detect line,
which is asserted only when there is actually valid audio data
being passed into the modem.
Initial tests with the audio modem and 2M XCVR on a
breadboard with equipment on hand were successful, but later
testing with the flight-capable radio was disappointing.. The
XCVR was stuck in transmit mode whenever it was plugged
into the modem board. After significant research, the cause
was found was to be an unexpected interaction between the
radio itself and the switch which controlled the flow of audio to
the radio. The radio has impedance-detecting circuitry in the
microphone input line in place of a separate transmit switch
line. The radio is in receive mode if a high-z state is detected,
and transmits when a low-Z state is present. The particular
radio used generated a 5V signal across its input terminals,
which was more than the 3.3V switch could handle. As a
result, the excess voltage was shunted through a protection
diode in the switch. The radio interpreted this reduction in
voltage as a low-z state, and consequently began transmitting.
This problem was temporarily resolved by over-volting the
switch, but a more permanent solution would be replacing the
audio switch with a natively 5V-tolerant device.
Text output from the OSD appeared clear and stable when
received correctly. Mismatched priorities in the ISR prioritized
the video output before the incoming serial communication,
occasionally garbling the incoming data. The mismatch led to
output of randomized data, which would then be corrected on
the next serial transmission.
For video transmission, the MAX2370 worked well for this
application; however, the power amplifier module was not
tested with the transmitter. The MAX2370 outputted the
camera signal to the television at a variable output power. This
allowed for tweaking of the output power to be inputted into the
power module. Also, the operational control register for the
MAX2370 included a shutdown bit to allow the shutdown of
the transmitter while the configuration register included IF and
Copyright © 2007 by Rochester Institute of Technology
Proceedings of the Multi-Disciplinary Engineering Design Conference
RF frequencies to be set so that the transmitter could be tuned
to the transmit frequency of 439.25MHz.
RECOMMENDATIONS FOR FUTURE WORK
As Project METEOR continues to develop, so must the
capabilities of its component systems. Future revisions of the
IP should include circuitry to enable the use of zero-pressure
balloons, which are more suited to long-duration high-altitude
flights. Also, the system must soon be able to test-fire a rocket
while aloft, so the IP must be equipped with hardware and
software needed to support such a test.
The board-stack concept first used in this revised platform
showed promise, but could be improved. Future systems
should use standardized bus lines, so that an arbitrary board can
be located in any position in the board stack without loss of
function..
The industry-standard PC/104 form factor may be a desirable
format to standardize on. PC/104 boards have common bus
lines, and there is good industry support of the standard.
Numerous low-power controller boards exist so future
designers should be able to find an appealing design.
The packet communication system used was somewhat limited
in its capabilities. A more advanced system that uses the
standard AX.25 protocol would be more useful and easier to
integrate into the exiting HAM radio network. The AX.25
protocol is difficult to implement in the MSP, but is included in
the Linux kernel. Future designers may wish to use a controller
board running Linux.
Page 8
Design Improvements
The program's final launch resulted in the loss of the prototype,
with a resulting loss of the onboard photo and video evidence
of the high-altitude launch. Since the system was not
recovered, the exact reasons for the failure could not be
ascertained. Future revisions of the platform should include
some sort of fail-safe tracking system that will not be sensitive
to disturbances in the rest of the system.
ACKNOWLEDGEMENTS








Dr. Dorin Patru, Team Mentor and Faculty Advisor
Dr. Jeff Kozak, Mechanical Engineering Advisor
Dr. Daniel Phillips, Electrical Engineering Faculty
Jim Stefano, Electrical Engineering Department
Ken Snyder, Electrical Engineering Department
Jeff Lonneville, CIMS Surface Mount Lab Manager
RAMLAB
Machine Shop
REFERENCES
[1] Indovina, J., Giannotti, M. , Shah, V., Matoba, R., and
Paasch, R. "Yaw controlled, balloon tethered platform for
METEOR Project," Team METEOR 2005/2006 Team,
Rochester Institute of Technology Multidisciplinary Senior
Design, May 2006
[2] Barrios, C., and Ayre, C. "Complete Design Review", Team
METEOR 2004/2005 Team, Rochester Institute of Technology
Multidisciplinary
Senior Design, May 2005
CONCLUSION
Design Successes
Two different iterations of the IP were successfully tested,
qualified, and flown. One of the launches yielded temperature
and pressure data that may be used to refine atmospheric
models used in future designs. Obsolete or under-performing
components were replaced with custom designs that worked
adequately in lab testing.
The ground-based APRS network infrastructure was extremely
useful. When the IP's APRS system was working properly, the
location of the balloon could be determined with a high degree
of certainly, which aided tracking and enabled quick recovery
of the system.
The final revision of the IP was the same weight as the old
platform, but was notably smaller. The complete system had a
feature set equal to or better than that of existing designs, but
had two digital video recorders in place of a single still digital
camera. This should have yielded exciting videos of the
platform's ascent and descent
[3] "Properties of Air over Temperature and Altitude," ThermoFlo
Dynamically Integrated Thermal Management Solutions,
http://www.thermaflo.com/air_properties.shtml
[4] Incropera, F., and Dewitt, D., Fundamentals of Heat and Mass
Transfer, 5th edition
[5] "Earth Atmosphere Model: Imperial Units," Glenn Research
Center, NASA, May 2006,
http://www.grc.nasa.gov/WWW/K-12/airplane/atmos.html
[6] Takeya, S., Nagaya, H., Matsuyama, T., Hondoh, T., and
Lipenkov, V. "Lattice Constants and Thermal Expansion
Coefficient of Air Clathrate Hydrate in Deep Ice Cores from
Vostok, Antarctica," ACS Publications, January 2000,
http://pubs.acs.org/cgibin/abstract.cgi/jpcbfk/2000/104/i04/abs/jp993344o.html
Paper Number P07103