RITedge.rit.edu/content/P07109/public/Admin Files...Project 20006: Yaw controlled, balloon tethered platform for METEOR Project 2005/2006 Team Michael Giannotti (EE) – Rina Matoba

Preliminary Design Review 5/12/2006

R⋅I⋅T Multi-Disciplinary Senior Design Kate Gleason College of Engineering

Rochester Institute of Technology Rochester, New York

November 2005

Microsystems Engineering and Technology for the Exploration of Outer Regions

Project 20006: Yaw controlled, balloon tethered platform for METEOR Project

2005/2006 Team

Michael Giannotti (EE) – Rina Matoba (ME) Richard Paasch (ME) – Vivek Shah (EE)

Jennifer Indovina (EE)

Preliminary Design Review

November 2005 Project 06005

Project 06005 Page 1 of 93


TABLE OF CONTENTS 1 Abstract......................................................................................................4 2 Introduction ...............................................................................................6 3 Objectives and Specifications ..................................................................7

3.1 Recognize and Quantify the Need ......................................................................... 7 4 Product Specification................................................................................8

4.1 Actuation System for Attitude and Location Control, ALC.................................. 8 4.2 Airborne Control Software, ACS........................................................................... 8 4.3 On Screen Telemetry Display, OSTD ................................................................... 8 4.4 Ground Control Software, GCS............................................................................. 8 4.5 Thermal Model and Analysis................................................................................. 9 4.6 Team Requirements ............................................................................................... 9 4.7 Stakeholders........................................................................................................... 9 4.8 Objectives ............................................................................................................ 10 4.9 Quarterly Gantt Charts......................................................................................... 11

5 Concept Development .............................................................................13 5.1 Actuation System for Attitude and Location Control, ALC................................ 13 5.2 Airborne Control Software, ACS......................................................................... 14 5.3 On Screen Telemetry Display, OSTD ................................................................. 17 5.4 Ground Control Software, GCS........................................................................... 18 5.5 Thermal Model and Analysis............................................................................... 19 5.6 System Diagram................................................................................................... 23 5.7 Launch Preparation Diagram ............................................................................... 24

6 Feasibility Analysis .................................................................................26 6.1 Limitations ........................................................................................................... 26 6.2 Pugh Analysis ...................................................................................................... 26 6.3 Quality Function Deployment.............................................................................. 30

7 Preliminary Analysis and Synthesis ......................................................36 7.1 Actuation System for Attitude and Location Control, ALC................................ 36 7.2 Airborne Control Software, ACS......................................................................... 38 7.3 On Screen Telemetry Display, OSTD ................................................................. 39 7.4 Ground Control Software, GCS........................................................................... 42 7.5 Thermal Model and Analysis............................................................................... 44

8 Conclusion................................................................................................48 9 Bibliography ............................................................................................49 10 Appendices ...........................................................................................50

10.1 Airborne Control Software (C source code) ........................................................ 50 10.2 Ground Control Software (C++ source code)...................................................... 50

10.2.1 DIJoystick.cpp ............................................................................................. 50 10.2.2 MeteorControl.cpp ....................................................................................... 73 10.2.3 MeteorControl.h........................................................................................... 75 10.2.4 MeteorControlDlg.cpp................................................................................. 76 10.2.5 MeteorControlDlg.h..................................................................................... 78

10.3 Bill of Materials (per launch)............................................................................... 80



10.4 Quality Function Deployment.............................................................................. 81 10.5 Pugh Charts.......................................................................................................... 86 10.6 Gantt Charts ......................................................................................................... 88 10.7 Functional Diagrams............................................................................................ 90 10.8 System Diagram................................................................................................... 91 10.9 Launch Preparation Diagram ............................................................................... 92



1 Abstract

METEOR is a university-based project, whose short-term goal is to launch and

place small payloads in low earth orbit, and whose long-term goal is to place such

payloads on near earth asteroids and lunar surfaces. Meteor is a hands-on, multi-phase,

multi-disciplinary, teaching and research program for investigating and developing

micro-systems engineering, science, and technologies for the exploration of outer

space.

This project will provide the RIT Engineering Department the ability to launch

small payload volumes for conducting micro-systems and other scientific experiments

into outer space. The Meteor Project will accommodate and promote multi-disciplinary

collaborations with the Electrical and Mechanical Engineering Departments. This

project also provides research opportunities for both undergraduate and graduate

students.

Figure 1.1 METEOR Platform/Pico-satellite Concept Launch, Courtesy of Project METEOR Concept Video, 2004



The METEOR Platform is a lightweight restructure that will be used to launch

satellites from already high altitudes. This means that the METEOR Platform is a cost

effective way to get payloads into space. Since the platform itself is lightweight, it can

be lifted into the upper troposphere using high altitude helium balloons and fall back

down to the surface of the Earth with a parachute system once its rocket/satellite

payload has been released. The retrievable platform will also be rebuilt with fewer off

the shelf components. Using custom built components will save money for the

resulting launches that will be required to test the propulsion system.

The image below represents what the design platform may look like at the end of

the Spring 2005-03 term. However, since the Propulsion system has not been built yet,

there might be changes during the build phase.

Figure 2.1 Possible Graphic Representation of the 2006 METEOR Platform



2 Introduction

The METEOR project is currently in its third phase, which consists of designing a

platform capable of reaching an altitude of about 100,000 feet utilizing helium filled,

high-altitude balloons. The successive designs of this platform will be the launching

point for future space bound missions. The design team is working on the program

through the Rochester Institute of Technology multi-disciplinary senior design project

and is composed of 5th year Electrical and Mechanical engineering students who are

enrolled in Senior Design I and II during the Fall 2005-01 and Spring 2005-03 quarters.

The subject matter that is incorporated in this phase of the design project includes

ground to platform radio communication, backup systems design, board layout

redesign, and an actuation system for attitude and location control of the platform.

Future work will include rocket, Pico-satellite, and space mission design.



3 Objectives and Specifications 3.1 Recognize and Quantify the Need

To exclude a 6-month Federal Aviation Administration (FAA) waiver application

process, the METEOR Platform below the balloon needs to weigh less than twelve

pounds. This however, does not include the weight of the future rocket appendages for

which the waiver will be required for other reasons.

The main design criteria for this years addition to the platform is as follows:

Custom hardware is to be included which will decrease weight and power consumption, perhaps a single board design to eliminate previous designs with over excessive wire usage.

A Thermal model will be created to ensure proper operation of all subsystems.

A Propulsion system will be attached to hull of the platform to control attitude

and rocket launch location.



4 Product Specification 4.1 Actuation System for Attitude and Location Control, ALC

The objective of the actuation system is to move the platform along the Earth’s

surface at 30 kilometers. The system will provide the future METEOR mission to have

safety features to guide the craft away from a populated area and assist mobile recovery

teams. Having this feature would allow confidence in our platform that it can safely fire

a rocket and allow the FAA to ease the weight restrictions our platform currently has.

4.2 Airborne Control Software, ACS

The primary function of the airborne control software is the idea of tracking the

platform in order to make it recoverable. Platform data such as the latitude, longitude,

altitude, speed, course, time, internal and external temperature, atmospheric pressure,

and acceleration in 3 axes are outputted two separate ways. The PIC outputs data to the

on screen display, which then transmits the data to the ground via the 70 cm band, and

the same data is also outputted in an APRS formatted packet to the TNC, which then

transmits the APRS formatted packet to the ground via the 2-meter band, so as to be

repeated in the APRS system.

4.3 On Screen Telemetry Display, OSTD

The redesigned OSD will have different parameters and guidelines than the original

OSD, thus it will be necessary to alter the current software to meet the specifications of

the different technology.

4.4 Ground Control Software, GCS

The objective of the ground control software is to provide manual control for the

propulsion system on the platform from the ground, and to allow the operator to have

full knowledge of the platform status during flight. This requires that the software use

some means for mechanical control, in this case a joystick, to interface with object-

oriented software and a graphical user interface. The interface itself will contain data



about the platform (such as internal and external temperatures), heading and speed, and

an orientation model of the platform, all within the GUI window. The GUI itself has

certain specifications that include:

Windows 98/2000 Operating System

Visual C++ .NET 6.0 Development Environment

UI View Software for Ground Control Monitoring

Microsoft Sidewinder Joystick

4.5 Thermal Model and Analysis

The thermal analysis model will contain the heat transfer information from the

platform, obtained during flight. Areas of the platform that will be observed include

external temperature, heat sources (circuit components), and radiation from the sun.

The number of holes in the platform hull will be considered in the 3D thermal model,

since the holes serve as a natural heat sink. However, comparison with actual data from

the launch will produce a better platform.

4.6 Team Requirements

The two previous senior student teams assigned to the METEOR Project have

designed and developed the platform up to the current version. The 2005/2006 Team will

develop the custom ground control software interface and GUI (GCS); customize the On

Screen Telemetry Display (OSTD); design a propeller based high altitude actuator

(ALC); create a thermal model of the platform; and the Airborne Control Software will

be extended to accommodate the system upgrades and changes (ACS).

This year’s team will not be required to have successful launches as part of the grade.

Only land-based testing of the individual subsystems is required by May 2006. However,

the Team has scheduled two launches in the Spring 2005-2006 term.

4.7 Stakeholders

Major stakeholders in the 2005/2006 METEOR Project include:



Dr. Dorin Patru, Team Mentor and Advisor

Dr. Robert Bowman and the Electrical Engineering Department, Project

Funding

Dr. Jeff Kozak, Mechanical Engineering Advisor

4.8 Objectives

The key goals of this term are to deliver a successful solution to the project needs

while respecting limitation, achieving schedule milestones, and limiting cost. The key

goals of the project are as follows:

Current budget of $2000.00

Design an integrated single board platform.

Platform is to have a total weight of less than 12 lbs (FAA regulations).

Design a lightweight transceiver with low power consumption.

Low power consumption is desirable so that fewer batteries are needed on the

platform, making the platform lighter.

Platform should be controlled from a ground station on demand, and it should

move a motor to change the position of the payload. The payload will

eventually be a rocket or a satellite.

Platform should reach an altitude higher than 30 kilometers (~100,000 feet),

and be stable for a certain period of time, at which the payload will perform its

purpose.

Platform should be 100% recoverable and reusable. This will reduce the cost of

rocket or satellite launching, by having a reusable launch pad that is inexpensive to use.



4.9 Quarterly Gantt Charts

Week 6 Week 7 Week 8 Week 9 Week 10Mike Code Reasearch METEOR 3 Launch METEOR 2005 Research PDR

CANCELLED Code ReasearchPeer Review

Vivek GPS research METEOR 3 Launch PDRCANCELLED 70cm Tx Research

Peer ReviewJennifer Basic GUI base METEOR 3 Launch Continue designing window PDR

Joystick and axis map CANCELLED Joystick applicationPeer Review

Rina Software research METEOR 3 Launch PDRTemperature Modeling CANCELLED Temperature ModelingPeer Review

Rich Determine reqs METEOR 3 Launch PDRfor propellor design CANCELLED Rotor Software SearchPeer Review

Fall 2005

Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10Mike Team Add code to software to integrate Verify

Meeting GUI, joystick, propeller motor, backup GPS PDRChanges

Vivek Team VerifyMeeting Update Documentation for PDR PDR

PCB Express Layout/Board Redesign ChangesJennifer Team Verify

Meeting Redo PDR Documentation PDRChanges

Rina Team VerifyMeeting Review new software PDR

ChangesRich Team Verify

Meeting Learn XROTOR Software PDRChanges

Winter 2005



Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10Mike Continue integration Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Results

Launch Repair Platform Launch Documentation CDRAssist w/ assembly Rebuild Platform

Vivek Begin assembly Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Resultsof platform for launch Launch Repair Platform Launch Documentation CDR

Rebuild PlatformJennifer Integrate software Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Results

with ACS Launch Rebuild Platform Launch Documentation CDRAssist w/ assembly

Rina Testing METEOR 3 Document Temp Data Testing METEOR 4 Review ResultsFluent / MATLAB Launch ANSYS Thermal Modeling Launch Documentation CDR

Rich Review software and Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Resultstest with motors Launch Rebuild Platform Launch Documentation CDRAssist w/ assembly

Spring 2005



5 Concept Development 5.1 Actuation System for Attitude and Location Control, ALC

Development of a propulsion system to control the attitude and location of the

platform requires more than one concept for consideration. The first is concept

considered is a direct current brush-less motor driven propeller. The second concept is

using a gas turbine propulsion unit, similar to the picture shown below.

(i) (ii)

Figure 3.1.1(i) Gas turbine on test stand (ii) Gas turbine mounted on model airplane

Courtesy of Tower Hobbies

The advantages of a gas turbine are that it would provide the most thrust compared

to the propeller, somewhere between 100 and 100,000 pounds of thrust (lbst.). However,

their weight ranges from 30-20,000 pounds (lbs.) making this an impossible choice for the

METEOR platform. A propeller at the target altitude of METEOR has very little air

density, therefore provides little thrust. A DC motor has an almost immediate response.

The propeller is the obvious choice due to its simplicity and ability to be designed and

constructed at RIT.




The Airborne Control Software (ACS) is responsible for coordinating the operation

of the PIC micro controller on the METEOR platform. The PIC allows for data links to

be made between the data transceiver and the different sensors and components in the

platform. The flow diagram of the software’s main loop is displayed in Figure 5.2.1.



Figure 5.2.1: Software Main Loop Flow Diagram Original Version, Courtesy of METEOR Team 2004/2005



The interrupt sequence for the ACS allows the main loop to be broken and specific commands sent from the ground to be implemented.

Figure 5.2.2: Software Interrupt Flow Diagram




The METEOR platform has four video cameras that are used by the ground control

team to monitor conditions around the METEOR platform. The 2005 METEOR team

used video overlay board to be able to overlay environmental and location data gathered

by the PIC onto the video stream from the video camera, before it is transmitted to the

ground station via the 70-cm radio transmitter. A block diagram of the video overlay

board is provided in Figure 5.3.1.

Figure 5.3.1: Block Diagram of OSD Design

The video overlay board was designed by Intuitive Circuits LLC and priced at

$99.00. A goal for the METEOR 2006 team is to reverse engineer the Intuitive Circuits

design such that the circuit can be built by the METEOR team, or to create a new design

of a video overlay board.

The inputs to the OSD System are the overlay text data and the composite video

input. The composite video input is a 1V peak-to-peak input signal containing sync data

and video data. The text overlay data can be sent via an RS-232 bus, I2C bus, or via a

UART. The output should be a 1V peak-to-peak composite video signal with 75Ω

impedance. In the new design component values also need to be chosen such that the

quality and performance specifications of the new design are as good, or better than the

Intuitive Circuits LLC design.

Three different types of On-Screen display systems were found. The first type is a

video amplifier system with a built in OSD. Its main purpose is to amplify RGB video

signals, and was designed for operation with devices such as computer monitors. The

second type is a TV microcontroller with a built in OSD. This type of system is built for

PIC Text Overlay Data

OSD Composite Video Output System

Composite Video Input



working with basic analog TV’s and can be made to take inputs from various devices that

interface with TV’s such as remote controls. Its main purpose is to take a composite

video signal from a 75Ω television cable overlay the data and provide an output in RGB

format. The final integrated circuit is one whose primary purpose is the OSD, and has no

other extra features. This system can take inputs from up to 8 composite video sources,

and provides outputs for up to 8 sources. The OSD characters that this system accepts

need to be stored into a memory, and the characters that are stored in the memory are

inputted by a microcontroller that communicates with the OSD.

If either the video amplifier system or TV microcontroller are used, then additional

components are needed for conversion between the RGB format to/from the specified

NTSC format. A video decoder can be used to convert the NTSC signal to an RGB

signal to obtain the required inputs for the video amplifier system. A video encoder

could be used on the outputs of both the video amplifier OSD and the TV

microcontroller. Although the standalone OSD would not need either of these two

components, an external 16Mb SDRAM is needed to store the OSD character

information.


The previous teams did not have a redundant method of storing flight data from the

platform. The new ground control software will allow the mission controller to remain

equipped with platform condition information throughout the launch, mission, and

recovery periods. The image in Figure 5.4.1 represents the functional diagram of the

software to hardware interface between the motors and ground control software.



Figure 5.4.1 Block Diagram of Ground Control Software


As the platform ascends through the atmosphere forced convection will occur on the

surface of the platform and free (otherwise known as natural) convection will occur

inside the platform. The heat created from circuit components will be conducted through

the platform and will increase the internal temperature.

Thermal model analysis will help future developments of the platform to be more

efficient in dispersing heat. Examples of the model were created to scale of the METEOR

Platform in two views of the cross section of the platform in 2D (time dependent in the

animation):

Closed platform without heat source (Figure 5.4.1, 2, 3) Closed platform with heat source (Figure 5.4.4, 5, 6)

Figure 5.4.1: Temperature model of the platform without heat source



Figure 5.4.2: Thermal gradient model of the platform without heat source (vector plot)

Figure 5.4.3: Thermal flux model of the platform without heat sources (element solution)



Figure 5.4.4: Temperature model of the platform with heat source (nodal solution)

Figure 5.4.5: Thermal gradient model of the platform with heat source (nodal solution)



Figure 5.5.6: Thermal flux model of the platform with heat source (nodal solution)



5.6 System Diagram

Motor

Actuator(Propeller)

70-cm Tx439.25 MHz

Video Overlay

Video Camera 1

GPS(Harris)

2 Internal Temp

Sensors

Pressure Sensor

3 Accelerometers

Digital Compass

RS232

/ 2Analog

TTL

RS232

Analog

/ 3Analog

Beacon

MAX232(RS232 Driver)

TTL

RS232

RS232

VIDEO MUX

Video Camera 2

Video Camera 3

Video Camera 4

DUAL UART MUX

TTL TTL

PIC

ADC

/ 3Select Lines

/ 3Select Lines

DEMUX

Power Control

2-m Tx/Rx

RTS Signal

TTL

/ 2Analog

2 External Temp

Sensors

TNCDuplexer

Analog Compass

Composite

Digital Compass

/ 4N S E W

Analog

Composite

Composite

Composite

Composite

/ 3Select Lines

GPS(Tyco)

FM Tx144.39 MHz

RS232 Driver

TTL

RS232

TNC

Tones

TTL

Driver(Joystick

Coordinates from 2-m Tx/Rx to PIC)

Photovoltaic Cells,

DC to DC Converter

Figure 5.6.1: System Diagram



The complete system flow diagram for this year’s platform design is located in the

figure above. The system flow diagram shows the connections between the external

platform components, software, and communication.

5.7 Launch Preparation Diagram

Many of the launch protocols were defined during the previous METEOR Teams

successful launches. These protocols have only been slightly altered. In order to have a

quicker retrieval time a second Mobile Command Station has been built and will be

tested during the METEOR III Launch. The plan is to use the same two-station design for

METEOR IV also. Reference the Mobile Command Diagrams in the figures in the

Appendix section.

Reference the Launch Preparation Flow Chart below, since it is the responsibility of

the Ground Control Operator to keep a mission on the pre-approved time schedule.



Figure 5.7.1: Launch Protocol Time Schedule and Diagram Also available in Appendix



6 Feasibility Analysis 6.1 Limitations

The limitations associated with this project are made clear using the Pugh Method of

analysis and comparison. The results of the analysis are located in the subsequent section.

The tables use a numerical base of 1 to relate characteristics of performance and

usability.

The QFD Analysis weighs the similarities between specifications and requirements in

order to relate the order of importance of tasks required for the project to be successful.

The major limitations associated with this project are:

FAA regulations (flight time, duration, location, and weight of platform)

Power consumption

Successful communications between the platform and ground control

Successful ground tests of the ALC

6.2 Pugh Analysis

CriteriaImportance

RankingWeighted Ranking

Visual C++ Studio .NET JAVA

Visual Basic IDE

Purchase Cost 7 0.1061 0.1061 0.1061 0.1061Operating Cost 7 0.1061 0.1061 0.1061 0.1061Cycle Time 10 0.1515 0.1515 0.0606 0.0303Mean time between failures 7 0.1061 0.1212 0.0909 0.1364Operating Time 10 0.1515 0.1515 0.0758 0.1061Constant operation 4 0.0606 0.0606 0.0758 0.0303

Mean Time to repair 7 0.1061 0.0909 0.0455 0.0606Current system compatibility 10 0.1515 0.1515 0.1212 0.1000Startup time 4 0.0606 0.0455 0.0152 0.0455Best Option based on weighted Criteria 1.0000 0.9848 0.6970 0.7212

Figure 6.3.1: Pugh Analysis for Ground Control Software (GCS)



Figure 6.3.2: Radar Chart Analysis for Ground Control Software (GCS)

CriteriaImportance


Single Propeller

Gas Turbine

Purchase Cost 8 0.1096 0.0959 0.0959Operating Cost 7 0.0959 0.0959 0.0959Response Time 10 0.1370 0.1370 0.0548Failure Time 9 0.1233 0.1096 0.0822Operating Time 10 0.1370 0.1370 0.0685Constant operation 8 0.1096 0.0548 0.0685Mean Time to repair 7 0.0959 0.0822 0.0411Current system compatibility 10 0.1370 0.1370 0.1096Startup time 4 0.0548 0.0411 0.0137Best Option based on weighted Criteria 1.0000 0.8904 0.6301

Visual C++ .NET Pugh Analysis

0.0000

0.0500

0.1000

0.1500

0.2000Purchase Cost

Operating Cost

Cycle Time

Mean time betw een failures

Operating TimeConstant operation

Mean Time to repair

Current system compatibility

Startup time

Visual C++ Studio .NET

JAVA

Visual Basic IDE

Figure 6.3.3: Pugh Analysis for Actuation System Attitude and Location Control (ALC)



Single Propeller Design Pugh Analysis

0.0000

0.0500

0.1000

0.1500Purchase Cost

Operating Cost

Response Time

Failure Time


Mean Time to repair


Startup time

Single PropellerGas Turbine

Figure 6.3.4: Radar Chart for Actuation System Attitude and Location System (ALC)

CriteriaImportance

RankingWeighted Ranking ANSYS ProE

System Stability 8 0.1290 0.1129 0.1129Ease of Use 7 0.1129 0.1129 0.1129Thermal Modeling Capability 10 0.1613 0.1613 0.0645Thermal Model 9 0.1452 0.1290 0.0968Correct results 10 0.1613 0.1613 0.0806Constant operation 8 0.1290 0.0645 0.0806

Mean Time to repair 7 0.1129 0.0968 0.0484Current system compatibility 1 0.0161 0.0161 0.1290Startup time 2 0.0323 0.0323 0.0161Best Option based on weighted Criteria 1.0000 0.8871 0.7419

Figure 6.3.5: Pugh Analysis for Thermal Model Software Comparison



Figure 6.3.6: Radar Chart for Thermal Model Software Comparison

Figure 6.3.7: Pugh Analysis for On Screen Telemetry Display

Thermal Model Pugh Analysis

0.0000

0.0500

0.1000

0.1500

0.2000System Stability

Ease of Use

Thermal Modeling Capability

Thermal Model

Correct resultsConstant operation

Mean Time to repair


Startup time

ANSYSProE

CriteriaImportance


Video Amplifier

OSDµC with

OSDOSD Video Generator

Purchase Cost 10 0.1493 0.1493 0.0746 0.0299Operating Cost 5 0.0746 0.0746 0.0896 0.0746Response Time 4 0.0597 0.0448 0.0597 0.0597Failure Time 10 0.1493 0.1343 0.1493 0.1343Operating Time 5 0.0746 0.0448 0.0597 0.0746Constant operation 10 0.1493 0.1493 0.1493 0.1493




Pugh Analysis of the On Screen Telemetry Display

0.0000

0.0200

0.0400

0.0600

0.0800

0.1000

0.1200

0.1400

0.1600Purchase Cost

Operating Cost

Response Time

Failure Time


Mean Time to repair


Startup time

Weighted RankingVideo Amplifier OSDµC with OSDOSD Video Generator

Figure 6.3.8: Radar Chart for On Screen Telemetry Display

.3 Quality Function Deployment

Due to the complex nature of this Senior Design Project, the Quality Function

De

6

ployment (QFD) has been separated to reflect each member’s contribution to the

design effort. Tasks such as launch preparation and testing are the responsibility of the

entire team, and therefore not represented in the individual QFD's.



Richard Paasch

Tasks

Flig

ht D

urat

ion

will

last

at l

east

~3

hour

s

Bat

tery

Life

will

last

~ 1

5 ho

urs

Gro

und

Con

trol T

rans

mis

sion

sha

ll ha

ve a

rang

e of

~1

00 m

iles

Pla

tform

Pow

er s

ourc

e sh

all b

e ab

le to

sup

port

amp-

hour

s fo

r 20

hour

s

Pla

tform

will

be

able

to d

eter

min

e in

stan

tane

ous

plat

form

spe

ed (s

ampl

e ev

ery

30 s

econ

ds)

Pla

tform

sha

ll be

abl

e to

mov

e/re

posi

tion

itsel

f with

in

0.5

met

ers

of m

ax h

eigh

t

Mot

or p

ower

con

sum

ptio

n w

ill b

e 5

mill

iam

ps fo

r no

mor

e th

an m

ax. f

light

dur

atio

n

Mot

or p

ower

sha

ll be

sup

plie

d by

bat

terie

s

Pla

tform

sha

ll by

abl

e to

repo

sitio

n in

self

with

in 0

.5

met

ers

Pla

tform

sha

ll be

abl

e to

pos

ition

itse

lf us

ing

prop

elle

rs

with

a m

inim

um s

peed

of 1

0 m

/sec

for 1

20 m

ins

Pla

tform

will

with

stan

d la

ndin

g ve

loci

ty o

f x m

/sec

Pla

tform

sha

ll be

retri

evab

le o

n an

y te

rrai

n or

alti

tude

Platform shall remain powered and functional for the duration of the flight 9 2 6 2 0 0 9 9 0 0 0Balloon and platform shall be able to reposition itself for a safe re-entry and landing 0 7 3 7 5 7 0 0 7 9 0

METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 7 0 7 1 0 0 0 0 0 9Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 0 0 0 0 0 0Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 0 0 0 7 0 0 7Platform shall be reusable 9 3 0 0 0 0 0 7 0 0 0Platform positioning efficiency will modeled during design and then measured during flight. 6 9 7 8 1 9 7 7 9 9 0Power consumption will modeled during design and then measured during flight. 6 9 7 8 0 7 9 9 7 7 0Non-integrated beacon sucessful in platform retrieval 5 0 7 5 0 0 0 0 0 0 0Pre-flight Ground Station operator 0 3 3 3 0 0 5 0 0 0 0Flight Ground Station operator 4 3 3 3 0 9 0 0 9 9 0Post-flight Ground Station operator 4 3 3 3 0 0 0 0 0 0 5Ground Station data server Analyst 4 3 3 3 0 0 0 0 0 0 0

Specifications

0

0

8

000

0

000070



Michael Giannotti

Tasks

Flig

ht D

urat

ion

will

last

at l

east

~3

hour

s

Bat

tery

Life

will

last

~ 1

5 ho

urs

Gro

und

Con

trol T

rans

mis

sion

sha

ll ha

ve a

rang

e of

~10

0 m

iles

Pla

tform

Pow

er s

ourc

e sh

all b

e ab

le to

sup

port

amp-

hour

s fo

r 20

hour

s

Pla

tform

will

be a

ble

to d

eter

min

e in

stan

tane

ous

plat

form

sp

eed

(sam

ple

ever

y 30

sec

onds

)

Pla

tform

will

con

tinuo

usly

con

sum

e ~3

00 m

a fo

r 15

hour

s

Bat

tery

con

sum

ptio

n w

ill be

less

than

x a

mp-

min

s

All

anal

og d

ata

will

be c

onve

rted

to d

igita

l with

x re

solu

tion

and

sam

pled

eve

ry x

mse

c

Pla

tform

sha

ll tra

nsm

it au

dibl

e an

d vi

sibl

e la

ndin

g po

sitio

n fo

r 100

mile

s

Mot

or C

ontro

ller w

ill ne

ed to

sup

ply

pow

er a

t x m

illia

mps

to

a m

otor

at 1

x R

PM

s

Pla

tform

will

be

able

to s

tore

1 k

byte

s of

dat

a if

data

tra

nsm

issi

on is

lost

Pla

tform

sha

ll tra

nsm

it w

hen

the

plat

form

mem

ory

buffe

r be

com

es 9

0% fu

ll

Platform shall remain powered and functional for the duration of the flight 9 2 6 2 0 5 2 6 2 0 4 9Platform shall be able to reach height and land 0 0 0 0 0 5 0 0 0 0 3 6Balloon and platform shall be able to reposition itself for a safe re-entry and landing 0 7 3 7 5 5 7 3 7 5 5 8Platform shall warn pedestrians upon re-entry 0 9 0 9 0 1 9 0 9 0 0 6

Platform shall disclose its position throughout the flight, re-entry and on ground 2 9 8 9 0 0 9 8 9 0 5 6

METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 7 0 7 1 4 7 0 7 1 4 0Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 4 7 8 3 3 4 5Ground Station will be able to transmit commands to Platform 4 7 8 8 0 5 7 8 8 0 5 6

Platform will be able to transmit to Ground Station real time video and digital data 4 7 9 8 3 5 7 9 8 3 5 8

Platform electronics will apply standard interface protocols (i.e. USB) 4 7 6 8 1 0 7 6 8 1 0 5

Platform will ensure reliable operation and apply redundant circuitry where necessary 0 7 6 8 0 0 7 6 8 0 0 5Platform shall store critical flight telemetry data until data transmission occurs 0 9 9 8 4 2 9 9 8 4 9 9Platform shall transmit all flight data 9 9 9 8 0 5 9 9 8 0 9 9Platform shall operate autonomously if communications with Ground Station is lost 4 7 1 8 0 5 7 1 8 0 5 9Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 0 4 0 0 0 0 4 4Platform will illuminate during re-entry 5 9 0 8 0 3 9 0 8 0 3 7Platform shall be reusable 9 3 0 0 0 0 3 0 0 0 0 0Non-integrated beacon sucessful in platform retrieval 5 0 7 5 0 0 0 7 5 0 2 5

Specifications



Vivek Shah

Tasks

Flig

ht D

urat

ion

will

last

at l

east

~3

hour

s

Bat

tery

Life

will

last

~ 1

5 ho

urs

Gro

und

Con

trol T

rans

mis

sion

sha

ll ha

ve a

rang

e of

~1

00 m

iles

Pla

tform

Pow

er s

ourc

e sh

all b

e ab

le to

sup

port

amp-

hour

s fo

r 20

hour

s

Pla

tform

will

be

able

to d

eter

min

e in

stan

tane

ous

plat

form

spe

ed (s

ampl

e ev

ery

30 s

econ

ds)

Pla

tform

sha

ll tra

nsm

it its

land

ing

with

in 2

0 m

eter

s fo

r 10

0 m

eter

dis

tanc

e

GP

S d

ata

gath

erin

g, s

tora

ge, a

nd tr

ansm

issi

on,

seco

ndar

y

LED

Fla

shin

g C

ircui

try/T

empe

ratu

re S

enso

r/Com

pass

OS

D-G

PS

Tex

t ove

rlay

METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 7 0 7 1 0 0 0Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 0 5 0Ground Station will be able to transmit commands to Platform 4 7 8 8 0 0 0 0Platform will be able to transmit to Ground Station real time video and digital data 4 7 9 8 3 0 0 0Platform electronics will apply standard interface protocols (i.e. USB) 4 7 6 8 1 0 0 0

Platform will ensure reliable operation and apply redundant circuitry where necessary 0 7 6 8 0 2 9 0Platform shall store critical flight telemetry data until data transmission occurs 0 9 9 8 4 0 9 0Platform shall transmit all flight data 9 9 9 8 0 0 0 5Platform shall operate autonomously if communications with Ground Station is lost 4 7 1 8 0 0 9 9Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 0 0 2 0Platform will illuminate during re-entry 5 9 0 8 0 0 0 9Platform shall be reusable 9 3 0 0 0 0 0 9during flight. 6 6 7 8 1 0 0 0Platform positioning efficiency will modeled during design and then measured during flight. 6 9 7 8 1 0 6 0Power consumption will modeled during design and then measured during flight. 6 9 7 8 0 0 0 0Non-integrated beacon sucessful in platform retrieval 5 0 7 5 0 0 0 0Define other data gathering sensors or experiments. 3 0 0 0 0 0 0 7Pre-flight Ground Station operator 0 3 3 3 0 0 0 0Flight Ground Station operator 4 3 3 3 0 0 0 0Post-flight Ground Station operator 4 3 3 3 0 0 0 0Ground Station data server Analyst 4 3 3 3 0 0 0 0

Specifications

0

90

90

0

09

00090

0

0920000



Rina Matoba

Tasks

Flig

ht D

urat

ion

will

last

at l

east

~3

hour

s

Bat

tery

Life

will

last

~ 1

5 ho

urs

Gro

und

Con

trol T

rans

mis

sion

sha

ll ha

ve a

rang

e of

~10

0 m

iles

Pla

tform

Pow

er s

ourc

e sh

all b

e ab

le to

sup

port

amp-

hour

s fo

r 20

hour

s

Pla

tform

will

be

able

to d

eter

min

e in

stan

tane

ous

plat

form

sp

eed

(sam

ple

ever

y 30

sec

onds

)

Sim

ulat

ion

resu

lts to

impa

ct d

esig

n

Tem

pera

ture

of e

lect

roni

cs s

hall

not e

xcee

d x

degr

ees

Def

ine

fligh

t the

rmo

sens

ors

to m

onito

r and

trac

k

Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 9 9Ground Station will be able to transmit commands to Platform 4 7 8 8 0 0 0Platform will be able to transmit to Ground Station real time video and digital data 4 7 9 8 3 0 0Platform shall store critical flight telemetry data until data transmission occurs 0 9 9 8 4 0 0Platform shall transmit all flight data 9 9 9 8 0 8 9Platform shall operate autonomously if communications with Ground Station is lost 4 7 1 8 0Platform shall be reusable 9 3 0 0 0 0 0Thermo-characteristics will be modeled during design and then measured during flight. 6 6 7 8 1 9 9

Platform positioning efficiency will modeled during design and then measured during flight. 6 9 7 8 1 0 0

Power consumption will modeled during design and then measured during flight. 6 9 7 8 0 0 0Radiation (i.e. heat build-up) will be measured during flight. 6 9 7 8 0 8 8Temperature Sensor monitoring internal and external temperatures (~20 C) 6 9 7 8 0 7 9

Specifications

80

0

07

0

9

0

08

8



Jennifer Indovina, Team Leader

Tasks

Flig

ht D

urat

ion

will

last

at l

east

~3

hour

s

Gro

und

Con

trol T

rans

mis

sion

sha

ll ha

ve a

rang

e of

~10

0 m

iles

Pla

tform

will

be

able

to d

eter

min

e in

stan

tane

ous

plat

form

sp

eed

(sam

ple

ever

y 30

sec

onds

)

Pla

tform

sha

ll tra

nsm

it au

dibl

e an

d vi

sibl

e la

ndin

g po

sitio

n fo

r 100

mile

s

Pla

tform

will

be

able

to s

tore

1 k

byte

s of

dat

a if

data

tra

nsm

issi

on is

lost

Pla

tform

sha

ll tra

nsm

it w

hen

the

plat

form

mem

ory

buffe

r be

com

es 9

0% fu

ll

Pla

tform

sha

ll tra

nsm

it its

land

ing

with

in 2

0 m

eter

s fo

r 100

m

eter

dis

tanc

e

Pla

tform

sha

ll be

retri

evab

le o

n an

y te

rrain

or a

ltitu

de

Gro

und

Con

trol s

oftw

are

- GU

I, flo

wch

art,

tele

met

ry d

ispl

ay,

and

long

term

sto

rage

Gro

und

cont

rol t

rans

mis

sion

sha

ll ha

ve a

rang

e of

x m

iles

Pla

tform

sha

ll tra

nsm

it ev

ery

~30

seco

nds

Platform shall remain powered and functional for the duration of the flight 9 6 0 2 4 9 5 0 3 3Platform shall be able to reach height and land 0 0 0 0 3 6 0 0 9 8Balloon and platform shall be able to reposition itself for a safe re-entry and landing 0 3 5 7 5 8 0 0 6 4Platform shall warn pedestrians upon re-entry 0 0 0 9 0 6 0 0 0 5Platform shall disclose its position throughout the flight, re-entry and on ground 2 8 0 9 5 6 9 9 8 3

METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 0 1 7 4 0 0 8 7 8Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 8 3 3 4 5 0 0 7 9

Ground Station will be able to transmit commands to Platform 4 8 0 8 5 6 0 0 9 5Platform will be able to transmit to Ground Station real time video and digital data 4 9 3 8 5 8 0 0 9 5Platform electronics will apply standard interface protocols (i.e. USB) 4 6 1 8 0 5 0 0 9 5

Platform will ensure reliable operation and apply redundant circuitry where necessary 0 6 0 8 0 5 2 0 0 0

Platform shall store critical flight telemetry data until data transmission occurs 0 9 4 8 9 9 0 0 6 3Platform shall transmit all flight data 9 9 0 8 9 9 0 0 8 4Platform shall operate autonomously if communications with Ground Station is lost 4 1 0 8 5 9 0 0 0 5Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 4 4 0 0 0 0Platform will illuminate during re-entry 5 0 0 8 3 7 0 0 0 0Platform positioning efficiency will modeled during design and then measured during flight. 6 7 1 8 2 2 0 0 9 7Non-integrated beacon sucessful in platform retrieval 5 7 0 5 2 5 0 0 0 0Define other data gathering sensors or experiments. 3 0 0 0 0 5 0 0 0 0Pre-flight Ground Station operator 0 3 0 3 9 0 0 0 9 9Flight Ground Station operator 4 3 0 3 9 5 0 0 9 8Post-flight Ground Station operator 4 3 0 3 6 0 0 7 9 9Ground Station data server Analyst 4 3 0 3 6 6 0 0 9 8pedestrians at landing zone 0 0 0 0 2 0 6 0 4 0Land owner at landing zone 0 0 0 0 2 0 0 0 1 0Chasers 4 0 0 0 5 0 6 0 1 3FAA Analyst (if pre-flight approval is needed) 0 0 0 0 0 0 0 0 1 0Equipment Transporters 0 0 0 0 6 0 0 0 1 0

Specifications

56

24

9

7

9

9

8

8

0

77

000

700444400020



7 Preliminary Analysis and Synthesis 7.1 Actuation System for Attitude and Location Control, ALC

Drag force is defined “the aerodynamic force that opposes an aircraft's motion through the air. ” Or simply by the equation:

DD CSVF 2

21

∞∞= ρ (Equation 1)

Before finding out the drag, Reynolds’s number must be determined:

∞

∞∞=µ

ρ dVRe (Equation 2)

The drag coefficient in Equation 1 is dependent on Reynolds’s number:

Figure 7.1.1: Drag coefficient for a uniform flow over a sphere as a function of the Reynold’s number Experimental data from Schlichting (1979), Achenbach (1972) and Maxworthy (1969)

If we go by Achenbach’s approximation, then the drag coefficient can be assumed to be 0.5.



Drag Force vs. Velocity

0

20

40

60

80

100

120

0 5 10 15 20 25Velocity (m/s)

Dra

g Fo

rce

(N)

Figure 7.1.2: Drag Force and Velocity Relationship

Note: This is the drag created by the balloon. Analysis of the parachute, box and

rocket will be ignored since their cross sectional area is very small compared to the balloon and will not create much drag.

Atmospheric Conditions

The National Oceanic & Atmospheric Administration (NOAA) supplies data of atmospheric conditions. While they do have data on wind speed, it is only up to ~14 kilometers (48,000 feet.)

Figure 7.1.3: Altitude and Wind Speed Relationship (meters vs. knots)



This is a graph showing the altitude versus wind speed taken over Riverton,

Wyoming in an August 2001 weather balloon launch. While wind speeds vary over

different regions of the Earth, this graph shows wind speed can get as much as ~15 knots

(~17.26 mph or ~7.71 m/s.) It is also evident that wind speeds vary from season to season

depending on the region. Since there is no data over the wind speed in our, an assumption

can be made that the platform can experience wind speeds close to these figures.

If the worst-case scenario were assumed of having a wind speed in the upper

atmosphere of 7.71 m/s, this would give us a drag force of roughly 10.3 Newtons (2.32

pounds.)

It has been decided that the propeller design will be done with XROTOR software.

The XROTOR software allows the designer to model and synthesize designs of

propellers.


Accurately extending the existing software program is a crucial task in the process

of obtaining proper functionality from new components. The main program file

(meteor.c) and header file (meteor.h) are neatly programmed and commented, which

simplifies the act of troubleshooting and lengthening the code.

Components being added to the system include a propulsion system, a custom

GPS unit, a ground control interface, and a redesigned OSD. A flow diagram of the PIC

is displayed below.



2 Internal Temp

Sensors

Pressure Sensor

3 Accelerometers

OO

PIC

ADC

O

2 External Temp

Sensors

Analog Compass

O

Tx/Rx

TNC

OSD

Video MUXCameras

Video Tx

GPS(Harris)

UART MUX//

//

X

*

**

*

Propeller Motor Driver

(Joystick Coordinates from Tx/Rx to PIC)

Digital Compass

\\

RS232 DriverO

O

TNC Interrupt

*

Digital Compass

O

*

X

X

Demux X

X

Legend

O Sensor Data // Video Signal X Telemetry * Digital Data

\\ Motor Control

O

\\

X X

X

Figure 7.2.1: PIC Microcontroller Flow Diagram

The on-board computer PIC18F2680 microcontroller and is able to maintain data

links between the data transceiver and the different sensors and components in the

platform. As the project becomes more complex, and includes more sensors and

actuators, the microcontroller should be able to keep an active link to all new

components. Using different interfaces the new microcontroller should be able to support

all the interfaces that are needed.


The SAA55XX microcontroller with OSD was chosen and a schematic for the system

was created. The block diagram of the OSD system is provided in Figure 7.3.1.



PIC Text &

Figure 7.3.1: Block Diagram of the OSD System

The three main components of this system are the SAA55XX microcontroller, the

AD723 RGB to NTSC video encoder, and the EL1883 video sync separator. Currently

many of the features of the microcontroller are not being used such as its various I/O

ports, and one of the I2C ports, but the PCB design of the system will make these ports

available to the outside in case the design changes and the need for these ports arise. The

video input is directly fed into a Chroma Filter, which is basically a low pass filter with a

cut off at 0.5MHz. This filter helps increase the signal-to-noise ratio of the composite-

video input, which is good to have especially for systems with space applications. The

output of the filter is sent to both the EL1883 sync separator and to the microcontroller.

The second input is an I2C data input and I2C clock that comes from the main computer

and provides the OSD data to be displayed over the video. The sync separator outputs

are composite sync, vertical sync, and horizontal sync. The composite sync output is not

used, and is thus left floating. The other two outputs are necessary for both the AD723

video encoder and the microcontroller. The RGB output of the microcontroller is fed

directly to the video encoder. The encoder then converts the RGB information into a

CVBS (color, video, and blanking signal) or composite video signal.

The design of the actual circuit requires other components such as passive devices

and clocks. The schematic is given below in Figure 7.3.2.

Clock Data

Composite Video Input

Composite Video Output

Microcontroller SAA55XX

RGB to NTSC Video Encoder AD723

Vertical Sync Separator EL1883

Chroma Filter

2 R

G B

HSYNC VSYNC



Figure 7.3.2: Schematic of the OSD System

One thing to note in the schematic is with the AD723. Along with the CVBS output

there are also luminance and chrominance outputs, which are not left floating. This is

done because the AD723 cannot operate with those outputs floating, even if the outputs

are not in use. The AD723 does have smart sensing to determine which of the outputs are

being used and limits the current outputs of the luminance and chrominance outputs

which are not in use. Two clocks are needed for this circuit, a 12MHz clock for the

microcontroller, and a 14.31818MHz clock for the AD723. Both clocks are readily

available and can be found on Digi-Key.

The EL1883 and AD723 are designed to operate at temperatures between -40°C and

80°C. The SAA55XX is designed to operate between 0°C and 70°C. The clocks have

also been chosen to operate between 0°C and 70°C. The overall design should be able to

work on a single 3.3V power supply between the temperature ranges of 0°C and 70°C.




The ground control software allows the person monitoring the platform at high

altitudes to send commands to the platform and operate joystick control of the

propeller based propulsion system, from the ground. Consisting of a graphical user

interface (GUI), joystick interface, joystick hardware, and the already utilized software

package UI View; the platform will be better controlled from the mission control

operator in the mobile command station.

Create Visual Window Object

display temp, pressure, heading

refresh PIC

get PIC stream data

0

1

display joystick data in window

joystick connection

get joystick data

joystick.c

Create Visual Window Object

send joystick position to motors

motors get data

send motor coordinates

check motor position

1

0

1

0

1

0

Figure 3.2.1: Ground Control Software Flow Chart



The METEOR Platform radio call sign is KCGXT-7. Since the ground control

operator is required to operate UI View to track the platform, amateur radio licensing is

mandatory.

The graphical user interface will be designed and implemented using C++ in the

Microsoft Visual Studio .NET development environment. This is a required system,

since the joystick and mobile command laptops are Microsoft compatible. Also, the

ACS software is written in C, choosing a C++ GUI will help make the portability of

information between the platform and the GUI simple. Figure 7.4.1 is of the current

GUI design, demonstrating the ability to control a joystick. The GUI will eventually

also be able to accept strings of data from the processor on the platform, utilizing the

ACS-GUI C structure.

Figure 7.4.1 Current Design of Ground Control Graphical User Interface




The thermal analysis of the platform allows us to observe the thermal model of the

platform throughout the launch. However, in ANSYS the time dependent heat transfer

model is observed at sea level, not as ascending through the atmosphere.

The animation of the transient thermal model does not show exactly how heat

transfer will occur throughout actual launching since there are differences in change of

temperature and density at the level of altitude in the air. Therefore comparing the actual

data and the result from ANSYS is necessary for more accurate observation.



Properties of the U.S. standard atmosphere

External

Temperature Time Altitude Density

Thermal

Conductivity

Specific

Heat

K ˚C s min m ft Kg/m3 W/m K J/kg K

288.15 15.0 0 0 0 0.0 1.221 25.35 1006.8

284.90 11.8 125 2 500 1640.4 1.165 25.09 1006.7

281.65 8.5 250 4 1000 3280.8 1.108 24.83 1006.6

275.15 2.0 500 8 2000 6561.7 1.005 24.31 1006.5

268.65 -4.5 750 13 3000 9842.5 0.907 23.79 1006.4

262.15 -11.0 1000 17 4000 13123.4 0.814 23.27 1006.2

255.65 -17.5 1250 21 5000 16404.2 0.732 22.75 1006.1

249.15 -24.0 1500 25 6000 19685.0 0.660 22.23 1006.0

242.65 -30.5 1750 29 7000 22965.9 0.588 21.68 1006.1

236.15 -37.0 2000 33 8000 26246.7 0.521 21.14 1006.3

229.65 -43.5 2250 38 9000 29527.6 0.464 20.59 1006.4

223.15 -50.0 2500 42 10000 32808.4 0.412 20.04 1006.5

216.65 -56.5 5000 83 20000 65616.8 0.088 19.50 1006.7

217.65 -55.5 5250 88 21000 68897.6 0.072 19.58 1006.6

218.65 -54.5 5500 92 22000 72178.5 0.062 19.67 1006.6

219.65 -53.5 5750 96 23000 75459.3 0.052 19.75 1006.6

220.65 -52.5 6000 100 24000 78740.2 0.041 19.83 1006.6

221.65 -51.5 6250 104 25000 82021.0 0.036 19.92 1006.6

222.65 -50.5 6500 108 26000 85301.8 0.031 20.00 1006.5

223.65 -49.5 6750 113 27000 88582.7 0.026 20.09 1006.5

224.65 -48.5 7000 117 28000 91863.5 0.021 20.17 1006.5

225.65 -47.5 7250 121 29000 95144.4 0.021 20.25 1006.5

226.65 -46.5 7500 125 30000 98425.2 0.015 20.34 1006.5

Table 6.4.1: Temperature, density, thermal conductivity, and specific heat of air at different

altitudes



Note:

• Time is assumed when the velocity is 3m/s.

• External temperature and density at different altitudes are calculated by using the

website: http://www.onlineconversion.com/atmosphere.htm.

• Thermal conductivity and specific heat at different temperature is calculated from

“Fundamental of Heat and Mass Heat Transfer by Frank P. Incropera and David P.

DeWitt” data.

Density (Kg/m3)

Thermal

Conductivity

(W/m·K)

Specific Heat

(J/kg·K)

Styrofoam 35 0.027 6.0185

Silicon (Circuit) 2329 124 2.561

Table 6.4.2.: Density, thermal conductivity, and specific heat of Styrofoam (platform) and

Silicon (circuit components).

Note:

• The data is from www.matweb.com



Temperature vs. altitude (m)

y = 2E-07x2 - 0.0074x + 287.11R2 = 0.9786

200.00

210.00

220.00

230.00

240.00

250.00

260.00

270.00

280.00

290.00

300.00

0 5000 10000 15000 20000 25000 30000 35000

Altitude (m)

Exte

rnal

Tem

pera

ture

(K)

temp. at diff. altitudePoly. (temp. at diff. altitude)

Figure 6.4.1.: Temperature change (K) vs. altitude (m) graph



8 Conclusion

With the completion of this project, RIT will have the means to do near-space

research and rocket deployment. The fact that this project is ongoing will require the

2005/2006 METEOR Team to do extensive analysis, testing, and documentation.

After defining the needs and goals of this project, it is now possible to explore the

different possibilities and means by which the goals can be achieved. This project will

give aerospace and other engineering facilities the ability to move forward with

previously inaccessible research methods.



9 Bibliography Complete Design Review, Team METEOR 2004/2005 Team, Carlos Barrios & Chris Ayre, May 2005 Florida International University, NASA, ALLSTAR Network: Aircraft Propulsion, Gas Turbines Operation and Design Requirements, http://www.allstar.fiu.edu/aero/turbine2.html, 1995-2006 Preliminary Design Review, Team METEOR 2004/2005 Team, Carlos Barrios & Chris Ayre, November 2004 MATWEB, Material Property Data, www.matweb.com, 1996-2006 Microsoft Visual .NET Studio, Microsoft Development Environment, 1987-2001 NASA Glenn Research Center, What is Drag?, http://www.grc.nasa.gov/WWW/K-12/airplane/drag1.html, 1995-2006 Tower Hobbies, http://www.towerhobbies.com, 1994-2005



10 Appendices 10.1 Airborne Control Software (C source code)

The source code for the Airborne Control Software was written by 2004/2005 METEOR Team member Carlos Barrios.

No significant changes have been made in the code. The revised ACS code will be in the 2005/2006 Meteor Team’s Complete Design Review (CDR).

10.2 Ground Control Software (C++ source code)

The source code for the Ground Control Software was written by 2005/2006 team member Jennifer Indovina.

10.2.1 DIJoystick.cpp // DIJoystick.cpp: implementation of the CDIJoystick class. // // Microsoft Foundation Classes // // Utilized by Jennifer Indovina // ////////////////////////////////////////////////////////////////////// #include "stdafx.h" #include "MeteorControl.h" #include "DIJoystick.h" #ifdef _DEBUG #undef THIS_FILE static char THIS_FILE[]=__FILE__; #define new DEBUG_NEW #endif // DIJoystick.cpp: implementation of the CDIJoystick class. #include "stdafx.h" #include "DIJoystick.h" #define BUFFERSIZE 16



// Set the maxmimum range to which we'll gauge the swing // JEN: the servo-motor range may be smaller - so adjust // the joystick grid accordingly. #define JOYMAX 10000 #define JOYMIN -10000 /* Y ^ | | X -10,000 <---*---> +10,000 | | \/ */ // Dead zone is the amount of sway the joystick can have before we start registering movement // In this case 20% #define JOYDEAD 2000 // The Saturation Point Is Where the Joystick is deemed to be at Full Swing, in this case 95% #define JOYSAT 9500 ////////////////////////////////////////////////////////////////////// // Construction/Destruction ////////////////////////////////////////////////////////////////////// CDIJoystick::CDIJoystick() // Initialize Member Variables m_EnumerationStarted=false; m_Initialized=false; m_hInstance=GetModuleHandle(NULL); // Initialize Direct Input Initialize(); // Start Enumeration of Attached Joysticks. Enumerate_Joysticks(); //////////////////////////////////////////////////////////////////////



// // Destroy The Direct Input Joystick Control and tidy up. // ////////////////////////////////////////////////////////////////////// CDIJoystick::~CDIJoystick() Shutdown(); ////////////////////////////////////////////////////////////////////// // // Initialize Direct Input // ////////////////////////////////////////////////////////////////////// bool CDIJoystick::Initialize() HRESULT hr; hr = DirectInputCreateEx(m_hInstance, DIRECTINPUT_VERSION, IID_IDirectInput7, (void**)&m_lpDI, NULL); if FAILED(hr) // DirectInput not available; // take appropriate action OutputDebugString("Failed To Initialize Direct Input 7 in CDIJoystick::Initialise\n"); OutputDebugString(GetDIError(hr)); return false; m_hwnd=NULL; if FAILED(hr) OutputDebugString(GetDIError(hr)); Shutdown(); return false; m_Initialized=true; return true; // Successfully Created Direct Input 7 Object ////////////////////////////////////////////////////////////////////// // // Shutdown the Direct input object and release it.



// // Basically clean up any memory allocated to this object // ////////////////////////////////////////////////////////////////////// void CDIJoystick::Shutdown() ClearFriendlyButtonNames(); // Remove Joystick Information if(!m_DIJoystickList.IsEmpty()) POSITION pos=m_DIJoystickList.GetHeadPosition(); LPVOID del=NULL; while(pos) del=static_cast<LPVOID>(m_DIJoystickList.GetNext(pos)); if(del) delete del; m_DIJoystickList.RemoveAll(); // Shutdown Direct Input! if (m_lpDI) if (m_lpDIDevice) // Always unacquire device before calling Release(). try Acquire(false); m_lpDIDevice->Release(); m_lpDIDevice = NULL; catch(...) OutputDebugString("Failed to Release Pointer in CDIJoystick::Shutdown\n"); try m_lpDI->Release();



m_lpDI = NULL; catch(...) OutputDebugString("Failed to Release DI7 Pointer in CDIJoystick::Shutdown\n"); m_Initialized=false; ////////////////////////////////////////////////////////////////////// // // Start the Enumeration Of Attached Joystick Devices. // ////////////////////////////////////////////////////////////////////// bool CDIJoystick::Enumerate_Joysticks() HRESULT hr=NULL; if(!m_Initialized) Initialize(); if(!m_lpDI) // Has a Direct Input Interface Already Been Initialized? hr = DirectInputCreateEx(m_hInstance, DIRECTINPUT_VERSION, IID_IDirectInput7, (void**)&m_lpDI, NULL); if FAILED(hr) OutputDebugString("Error in CDIJoystick::Enumerate_Joysticks()\n"); OutputDebugString(GetDIError(hr)); return false; if(m_lpDI) hr=m_lpDI->EnumDevices(DIDEVTYPE_JOYSTICK ,EnumDevicesProc,this,DIEDFL_ATTACHEDONLY); if FAILED(hr) OutputDebugString("Error in CDIJoystick::Enumerate_Joysticks()\n"); OutputDebugString(GetDIError(hr)); return false;



OutputDebugString("Enumerating Joystick Devices\n"); return true; ////////////////////////////////////////////////////////////////////// // // Add Enumerated Devices To A Link List Object // Continue Enumeration Of The Device // ////////////////////////////////////////////////////////////////////// BOOL CDIJoystick::EnumDevicesProc(LPCDIDEVICEINSTANCE lpddi, LPVOID pvRef) CDIJoystick *obj=(CDIJoystick*)(pvRef); obj->AddDeviceInfo(lpddi); return DIENUM_CONTINUE; ////////////////////////////////////////////////////////////////////// // // Add Device Info To The List Of Pointers Held in m_DIJoystickList // // return true = Successfully Added // false = Failed To Add // ////////////////////////////////////////////////////////////////////// bool CDIJoystick::AddDeviceInfo(LPCDIDEVICEINSTANCE lpddi) m_EnumerationStarted=true; LPCDIDEVICEINSTANCE lpdi2=new DIDEVICEINSTANCE; if(lpdi2) memcpy((void*)lpdi2,lpddi,sizeof(DIDEVICEINSTANCE)); if(m_DIJoystickList.AddHead((void*)lpdi2))return true; OutputDebugString("Failed To Add Device Info in CDIJoystick::AddDeviceInfo(LPCDIDEVICEINSTANCE lpddi)\n"); return false; ////////////////////////////////////////////////////////////////////// // // Return First Joystick Device Data If Possible



// // return NULL if Failed or No Joysticks Available // ////////////////////////////////////////////////////////////////////// LPCDIDEVICEINSTANCE CDIJoystick::GetFirstJoystickID() if(!m_EnumerationStarted) OutputDebugString("Joystick Have Not Yet Been Enumerated Returning NULL from CDIJoystick::GetFirstJoystickID()\n"); return NULL; if(m_DIJoystickList.IsEmpty()) OutputDebugString("Joysticks Have Been Enumerated However None Were Found Attached To This System\n" "Therefore I am Returning NULL from CDIJoystick::GetFirstJoystickID()\n"); return NULL; m_DevicePOS=m_DIJoystickList.GetHeadPosition(); return GetNextJoystickID(); LPCDIDEVICEINSTANCE info=static_cast<LPCDIDEVICEINSTANCE>(m_DIJoystickList.GetNext(m_DevicePOS)); return info; ////////////////////////////////////////////////////////////////////// // // Return Next Joystick Device Data If Possible // // return NULL if Failed or No Joysticks Available // ////////////////////////////////////////////////////////////////////// LPCDIDEVICEINSTANCE CDIJoystick::GetNextJoystickID() if(!m_DevicePOS) return NULL; return static_cast<LPCDIDEVICEINSTANCE>(m_DIJoystickList.GetNext(m_DevicePOS));



////////////////////////////////////////////////////////////////////// // // Return First Joystick Button Name Data If Possible // // return NULL if Failed or No Joysticks Available // ////////////////////////////////////////////////////////////////////// TCHAR* CDIJoystick::GetFirstButtonName() if(!m_EnumerationStarted) OutputDebugString("Joystick Have Not Yet Been Enumerated\nor None attached to this systemReturning NULL from CDIJoystick::GetFirstJoystickID()\n"); return NULL; if(m_DIButtonNames.IsEmpty()) OutputDebugString("Joysticks Have Been Enumerated However None Were Found Attached To This System\n" "Therefore I am Returning NULL from CDIJoystick::GetFirstButtonName()\n"); return NULL; m_ButtonPOS=m_DIButtonNames.GetHeadPosition(); TCHAR* info=static_cast<TCHAR*>(m_DIButtonNames.GetNext(m_ButtonPOS)); return info; ////////////////////////////////////////////////////////////////////// // // Return First Joystick Button Name Data If Possible // // return NULL if Failed or No Joysticks Available // ////////////////////////////////////////////////////////////////////// TCHAR* CDIJoystick::GetNextButtonName() if(!m_ButtonPOS) return NULL; return static_cast<TCHAR*>(m_DIButtonNames.GetNext(m_ButtonPOS));



////////////////////////////////////////////////////////////////////// // // Create the Joystick Device Using GUID Passed // ////////////////////////////////////////////////////////////////////// bool CDIJoystick::CreateDevice(GUID *guid) HRESULT hr=NULL; // If a device already exists and is created, Release it. if (m_lpDIDevice) // Always unacquire device before calling Release(). try hr=m_lpDIDevice->Unacquire(); catch(...) try hr=m_lpDIDevice->Release(); if(FAILED(hr)) OutputDebugString(GetDIError(hr)); else m_lpDIDevice = NULL; catch(...) OutputDebugString("Failed to Release Pointer in CDIJoystick::CreateDevice(GUID *guid)\n"); // Check to see that Direct Input has been created and initialized. if(!m_lpDI) OutputDebugString("Failed to Create DI 7 interface to device in CDIJoystick::CreateDevice(GUID *guid) m_lpDI not initialized.\n"); return false;



// Attempt to create the device based on the GUID passed to this routine hr=m_lpDI->CreateDeviceEx(*guid,IID_IDirectInputDevice7,(void**)&m_lpDIDevice,NULL); if(FAILED(hr)) OutputDebugString("Failed to Create DI 7 interface to device in CDIJoystick::CreateDevice(GUID *guid)\n"); return false; // We must have been successful at this point. // Therefore copy the GUID to this members instance for future reference. memcpy(&m_JoystickGUID,guid,sizeof(GUID)); return true; ////////////////////////////////////////////////////////////////////// // // Return How Many Buttons The Attached Device Has Installed // When giving the player an option of which joystick to use // You may wish to evaluate the buttons available per attached device. // Returns the number of buttons for the currently selected device. // ////////////////////////////////////////////////////////////////////// int CDIJoystick::HowManyButtons() DIDEVICEOBJECTINSTANCE didoi; DWORD x; DWORD dwOfs; int count=0; HRESULT hr=NULL; ClearFriendlyButtonNames(); //if(m_lpDIDevice) if(InitDevice()) ZeroMemory(&didoi,sizeof(DIDEVICEOBJECTINSTANCE)); didoi.dwSize = sizeof( didoi ); for ( x = 0; x < 32; x++ ) dwOfs = DIJOFS_BUTTON( x );



hr=m_lpDIDevice->GetObjectInfo( &didoi, dwOfs, DIPH_BYOFFSET ); if ( SUCCEEDED( hr ) ) count++; TCHAR* name=new char[sizeof(didoi.tszName)]; // Should include UNICODE support here. strcpy(name,didoi.tszName); // Add the button name to the Pointer List for future reference. m_DIButtonNames.AddTail(name); else OutputDebugString(GetDIError(hr)); return count; // How many buttons did we find? //////////////////////////////////////////////////////////////////////// // // Shutdown the the link list of Friendly Button Names // //////////////////////////////////////////////////////////////////////// void CDIJoystick::ClearFriendlyButtonNames() try if(!m_DIButtonNames.IsEmpty()) POSITION pos=m_DIButtonNames.GetHeadPosition(); LPVOID del=NULL; while(pos) del=static_cast<LPVOID>(m_DIButtonNames.GetNext(pos)); if(del) delete del;



m_DIButtonNames.RemoveAll(); catch(...) OutputDebugString("Some unforseen error occurred in CDIJoystick::ClearFriendlyButtonNames()\n"); ////////////////////////////////////////////////////////////////////// // // Initialize The Joystick! // ////////////////////////////////////////////////////////////////////// bool CDIJoystick::InitJoystick() // Set range. // Note: range, deadzone, and saturation are being set for the // entire device. This could have unwanted effects on // sliders, dials, etc. DIPROPRANGE diprg; diprg.diph.dwSize = sizeof( diprg ); diprg.diph.dwHeaderSize = sizeof( diprg.diph ); diprg.diph.dwObj = 0; diprg.diph.dwHow = DIPH_DEVICE; diprg.lMin = JOYMIN; diprg.lMax = JOYMAX; if ( FAILED( m_lpDIDevice->SetProperty( DIPROP_RANGE, &diprg.diph ) ) ) return FALSE; // Set deadzone. DIPROPDWORD dipdw; dipdw.diph.dwSize = sizeof( dipdw ); dipdw.diph.dwHeaderSize = sizeof( dipdw.diph ); dipdw.diph.dwObj = 0; dipdw.diph.dwHow = DIPH_DEVICE; dipdw.dwData = JOYDEAD; if ( FAILED( m_lpDIDevice->SetProperty( DIPROP_DEADZONE, &dipdw.diph ) ) ) return FALSE;



// Set saturation. dipdw.dwData = JOYSAT; if ( FAILED( m_lpDIDevice->SetProperty( DIPROP_SATURATION, &dipdw.diph ) ) ) return FALSE; // Find out if force feedback available. DIDEVCAPS didc; didc.dwSize = sizeof( DIDEVCAPS ); if ( FAILED( m_lpDIDevice->GetCapabilities( &didc ) ) ) return FALSE; m_FFAvailable = ( didc.dwFlags & DIDC_FORCEFEEDBACK ); // If it's a force feedback stick, turn off autocenter so it doesn't // get in the way of our effects. if ( m_FFAvailable ) DIPROPDWORD DIPropAutoCenter; DIPropAutoCenter.diph.dwSize = sizeof( DIPropAutoCenter ); DIPropAutoCenter.diph.dwHeaderSize = sizeof( DIPROPHEADER ); DIPropAutoCenter.diph.dwObj = 0; DIPropAutoCenter.diph.dwHow = DIPH_DEVICE; DIPropAutoCenter.dwData = 0; m_lpDIDevice->SetProperty( DIPROP_AUTOCENTER, &DIPropAutoCenter.diph ); return TRUE; ////////////////////////////////////////////////////////////////////// // // Initialize The Joystick Device // ////////////////////////////////////////////////////////////////////// bool CDIJoystick::InitDevice() HRESULT hr; DIDEVICEINSTANCE diDeviceInstance; // Just a precaution when Enumerating Devices and button Names if you create // An options Dialog before creating your main gaming window. // Then simply use the desktop window, temporarily! if(!m_hwnd)m_hwnd=::GetDesktopWindow(); // Release device if it already exists.



if ( m_lpDIDevice ) //if ( m_FFAvailable ) ReleaseEffects(); Acquire( false); hr=m_lpDIDevice->Release(); if(FAILED(hr)) OutputDebugString("Error Releasing Interface in CDIJoystick::InitDevice()\n"); OutputDebugString(GetDIError(hr)); else m_lpDIDevice=NULL; // Create game device and set IDirectInputDevice7 interface in m_lpDIDevice. if(!CreateDevice( &m_JoystickGUID )) OutputDebugString("Failed to create device in CDIJoystick::InitDevice()\n"); return false; // Find out what type it is and set data format accordingly. diDeviceInstance.dwSize = sizeof( DIDEVICEINSTANCE ); hr=m_lpDIDevice->GetDeviceInfo( &diDeviceInstance ); if ( FAILED( hr ) ) OutputDebugString("Failed to obtain device info in CDIJoystick::InitDevice()\n"); OutputDebugString(GetDIError(hr)); return false; // Set the data format to be a Joystick hr = m_lpDIDevice->SetDataFormat( &c_dfDIJoystick2 ); if ( FAILED( hr ) ) OutputDebugString("Failed to create device in CDIJoystick::InitDevice()\n"); OutputDebugString(GetDIError(hr)); return false;



// Set cooperative level. DWORD cl, cl1; cl = DISCL_EXCLUSIVE; // Set foreground level for release version, but use background level // for debugging so we don't keep losing the device when switching to // a debug window. //cl1 = DISCL_FOREGROUND; cl1 = DISCL_BACKGROUND; #ifdef _DEBUG cl1 = DISCL_BACKGROUND; #endif // now set the co-operation level. hr=m_lpDIDevice->SetCooperativeLevel( m_hwnd, cl | cl1 ); if ( FAILED( hr )) OutputDebugString( "Failed to set game device cooperative level.\n" ); OutputDebugString(GetDIError(hr)); return false; // Set up the data buffer. DIPROPDWORD dipdw = // The header. sizeof( DIPROPDWORD ), // diph.dwSize sizeof( DIPROPHEADER ), // diph.dwHeaderSize 0, // diph.dwObj DIPH_DEVICE, // diph.dwHow , // Number of elements in data buffer. BUFFERSIZE // dwData ; hr=m_lpDIDevice->SetProperty( DIPROP_BUFFERSIZE, &dipdw.diph ); if(FAILED(hr)) OutputDebugString( "Failed to set up Data Buffer property.\n" ); OutputDebugString(GetDIError(hr)); return false;



// Resest the Force Feedback Flag m_FFAvailable = FALSE; // Try and initialize the Joystick! if ( !InitJoystick() ) return FALSE; // In case you were wondering, this is not a good time to acquire the // device. For one thing, we can't acquire in foreground mode here // because the options dialog may be open. We'll acquire it when the // main window is activated. return TRUE; //////////////////////////////////////////////////////////////////////////////// // // Either Acquire or Unacquire the Device! // //////////////////////////////////////////////////////////////////////////////// bool CDIJoystick::Acquire(bool state) HRESULT hr; if(!m_lpDIDevice) OutputDebugString("Error in CDIJoystick::Acquire(bool state)\nDevice Has Not Been Created.\n"); return false; if ( !state ) // Unacquire. hr = m_lpDIDevice->Unacquire(); else // Acquire. // This could take a while with FF. ::SetCursor( m_hCursorWait ); hr = m_lpDIDevice->Acquire(); if ( SUCCEEDED( hr ) ) // Initialize effects; ignore failure and just // pretend FF not there. if ( m_FFAvailable ) // First set when device initialized.



//m_FFAvailable = InitFFEffects(); if(FAILED(hr)) OutputDebugString("Failed in CDIJoystick::Acquire(bool state)\n"); OutputDebugString(GetDIError(hr)); return false; return true; ////////////////////////////////////////////////////////////////////// // // Set the HWND that will be used when Acquiring Devices! // ////////////////////////////////////////////////////////////////////// void CDIJoystick::SetHWND(HWND hwnd) //Shutdown(); m_hwnd=hwnd; //m_EnumerationStarted=false; m_hInstance=GetModuleHandle(NULL); // Initialize Direct Input //Initialize(); // Start Enumeration of Attached Joysticks. //Enumerate_Joysticks(); ////////////////////////////////////////////////////////////////////// // // Set the preferred GUID for the joystick device // ////////////////////////////////////////////////////////////////////// void CDIJoystick::SetPreferredDevice(GUID *pguid) memcpy(&m_JoystickGUID,pguid,sizeof(GUID)); ////////////////////////////////////////////////////////////////////// // // Re-Initialize this object, used when changing HWND or Device



// Not yet implemented. // ////////////////////////////////////////////////////////////////////// bool CDIJoystick::ReInitialize() // m_EnumerationStarted=false; // m_hInstance=GetModuleHandle(NULL); // Enumerate_Joysticks(); return true; ////////////////////////////////////////////////////////////////////// // // Return Error Text From HRESULT // ////////////////////////////////////////////////////////////////////// TCHAR* CDIJoystick::GetDIError(HRESULT error) switch(error) case E_PENDING : return _T("E_PENDING : Data Not Available.\n"); break; case E_HANDLE : return _T("E_HANDLE : The HWND parameter is not a valid top-level window that belongs to the process.\n"); break; case DIERR_UNSUPPORTED : return _T("DIERR_UNSUPPORTED : The function called is not supported at this time. This value is equal to the E_NOTIMPL standard COM return value.\n"); break; case DIERR_UNPLUGGED : return _T("DIERR_UNPLUGGED : The operation could not be completed because the device is not plugged in.\n"); break; case DIERR_REPORTFULL : return _T("DIERR_REPORTFULL : More information was requested to be sent than can be sent to the device.\n"); break; case DIERR_READONLY : return _T("DIERR_READONLY : The specified property cannot be changed. This value is equal to the E_ACCESSDENIED standard COM return value.\n"); break; case DIERR_OUTOFMEMORY : return _T("DIERR_OUTOFMEMORY : The DirectInput subsystem could not allocate sufficient memory to complete the call. This value is equal to the E_OUTOFMEMORY standard COM return value.\n"); break; // case DIERR_OTHERAPPHASPRIO : return _T("DIERR_OTHERAPPHASPRIO : Another application has a higher priority level, preventing this call from succeeding. This value is equal to the E_ACCESSDENIED standard COM return value. This error can be



returned when an application has only foreground access to a device but is attempting to acquire the device while in the background. "); // break; case DIERR_OLDDIRECTINPUTVERSION : return _T("DIERR_OLDDIRECTINPUTVERSION : The application requires a newer version of DirectInput.\n"); break; case DIERR_OBJECTNOTFOUND : return _T("DIERR_OBJECTNOTFOUND : The requested object does not exist.\n"); break; case DIERR_NOTINITIALIZED : return _T("DIERR_NOTINITIALIZED : This object has not been initialized.\n"); break; // case DIERR_NOTFOUND : return _T("DIERR_NOTFOUND : The requested object does not exist.\n"); // break; case DIERR_NOTEXCLUSIVEACQUIRED : return _T("DIERR_NOTEXCLUSIVEACQUIRED : The operation cannot be performed unless the device is acquired in DISCL_EXCLUSIVE mode.\n"); break; case DIERR_NOTDOWNLOADED : return _T("DIERR_NOTDOWNLOADED : The effect is not downloaded.\n"); break; case DIERR_NOTBUFFERED : return _T("DIERR_NOTBUFFERED : The device is not buffered. Set the DIPROP_BUFFERSIZE property to enable buffering.\n"); break; case DIERR_NOTACQUIRED : return _T("DIERR_NOTACQUIRED : The operation cannot be performed unless the device is acquired.\n"); break; case DIERR_NOINTERFACE : return _T("DIERR_NOINTERFACE : The specified interface is not supported by the object. This value is equal to the E_NOINTERFACE standard COM return value.\n"); break; case DIERR_NOAGGREGATION : return _T("DIERR_NOAGGREGATION : This object does not support aggregation.\n"); break; case DIERR_MOREDATA : return _T("DIERR_MOREDATA : Not all the requested information fit into the buffer.\n"); break; case DIERR_INVALIDPARAM : return _T("DIERR_INVALIDPARAM : An invalid parameter was passed to the returning function, or the object was not in a state that permitted the function to be called. This value is equal to the E_INVALIDARG standard COM return value.\n"); break; case DIERR_INPUTLOST : return _T("DIERR_INPUTLOST : Access to the input device has been lost. It must be reacquired.\n");



break; case DIERR_INCOMPLETEEFFECT : return _T("DIERR_INCOMPLETEEFFECT : The effect could not be downloaded because essential information is missing. For example, no axes have been associated with the effect, or no type-specific information has been supplied.\n"); break; // case DIERR_HANDLEEXISTS : return _T("DIERR_HANDLEEXISTS : The device already has an event notification associated with it. This value is equal to the E_ACCESSDENIED standard COM return value.\n"); // break; case DIERR_GENERIC : return _T("DIERR_GENERIC : An undetermined error occurred inside the DirectInput subsystem. This value is equal to the E_FAIL standard COM return value.\n"); break; case DIERR_HASEFFECTS : return _T("DIERR_HASEFFECTS : The device cannot be reinitialized because there are still effects attached to it.\n"); break; case DIERR_EFFECTPLAYING : return _T("DIERR_EFFECTPLAYING : The parameters were updated in memory but were not downloaded to the device because the device does not support updating an effect while it is still playing.\n"); break; case DIERR_DEVICENOTREG : return _T("DIERR_DEVICENOTREG : The device or device instance is not registered with DirectInput. This value is equal to the REGDB_E_CLASSNOTREG standard COM return value.\n"); break; case DIERR_DEVICEFULL : return _T("DIERR_DEVICEFULL : The device is full.\n"); break; case DIERR_BETADIRECTINPUTVERSION : return _T("DIERR_BETADIRECTINPUTVERSION : The application was written for an unsupported prerelease version of DirectInput.\n"); break; case DIERR_BADDRIVERVER : return _T("DIERR_BADDRIVERVER : The object could not be created due to an incompatible driver version or mismatched or incomplete driver components.\n"); break; case DIERR_ALREADYINITIALIZED : return _T("DIERR_ALREADYINITIALIZED : This object is already initialized\n"); break; case DIERR_ACQUIRED : return _T("DIERR_ACQUIRED : The operation cannot be performed while the device is acquired.\n"); break; case DI_TRUNCATEDANDRESTARTED : return _T("DI_TRUNCATEDANDRESTARTED : Equal to DI_EFFECTRESTARTED | DI_TRUNCATED\n"); break;



case DI_TRUNCATED : return _T("DI_TRUNCATED : The parameters of the effect were successfully updated, but some of them were beyond the capabilities of the device and were truncated to the nearest supported value.\n"); break; case DI_PROPNOEFFECT : return _T("DI_PROPNOEFFECT : The change in device properties had no effect. This value is equal to the S_FALSE standard COM return value.\n"); break; case DI_POLLEDDEVICE : return _T("DI_POLLEDDEVICE : The device is a polled device. As a result, device buffering does not collect any data and event notifications is not signaled until the IDirectInputDevice7::Poll method is called.\n"); break; case DI_OK : return _T("DI_OK : The operation completed successfully. This value is equal to the S_OK standard COM return value.\n"); break; // case DI_NOTATTACHED : return _T("DI_NOTATTACHED : The device exists but is not currently attached. This value is equal to the S_FALSE standard COM return value.\n"); // break; // case DI_NOEFFECT : return _T("DI_NOEFFECT : The operation had no effect. This value is equal to the S_FALSE standard COM return value.\n"); // break; case DI_EFFECTRESTARTED : return _T("DI_EFFECTRESTARTED : The effect was stopped, the parameters were updated, and the effect was restarted.\n"); break; case DI_DOWNLOADSKIPPED : return _T("The parameters of the effect were successfully updated, but the effect could not be downloaded because the associated device was not acquired in exclusive mode.\n"); break; // case DI_BUFFEROVERFLOW : return _T("DI_BUFFEROVERFLOW : The device buffer overflowed and some input was lost. This value is equal to the S_FALSE standard COM return value.\n"); // break; default: return _T("Unknown Error Code.\n"); ////////////////////////////////////////////////////////////////////////////////////////// // // Update member variables to reflect the state of the device // ////////////////////////////////////////////////////////////////////////////////////////// bool CDIJoystick::PollDevice() static loopcount=0;



HRESULT hr; //DIDEVICEOBJECTDATA rgdod[BUFFERSIZE]; //DWORD dwItems; ZeroMemory(&m_dijs,sizeof(m_dijs)); // Has device been initialized ? if (!m_lpDIDevice) // Try and initialize device if(!InitDevice()) OutputDebugString("Failed To Initialize and Poll Joystick in CDIJoystick::PollDevice()\n"); return false; hr=m_lpDIDevice->Poll(); // May be unnecessary but never hurts. if(FAILED(hr)) OutputDebugString("Failed To Poll Joystick in CDIJoystick::PollDevice()\n"); OutputDebugString(GetDIError(hr)); getImmediateData: if(loopcount>20) return false; // Infinite Loop Protection hr = m_lpDIDevice->GetDeviceState( sizeof( DIJOYSTATE2 ), &m_dijs ); // The data stream was interrupted. Reacquire the device and try again. if ( hr == DIERR_INPUTLOST ) OutputDebugString("Failed To Obtain Immediate Device State in CDIJoystick::PollDevice()\n"); OutputDebugString(GetDIError(hr)); // Increment Infinite Loop Protection Counter and try again. loopcount++; // Try and acquire device and start again. if ( Acquire( true ) ) goto getImmediateData; // We can't get the device because it has not been acquired so try and acquire it. if ( hr == DIERR_NOTACQUIRED )



// Increment Infinite Loop Protection Counter. loopcount++; OutputDebugString("Device Not Acquired Trying Again immediate CDIJoystick::PollDevice()\n"); if(!Acquire(true)) OutputDebugString("Unable to acquire Immediate Device in CDIJoystick::PollDevice() Quitting\n"); return false; // Try and get buffered data if device is buffered! goto getImmediateData; if ( FAILED(hr)) OutputDebugString("Unable to obtain Immediate Data from Device in CDIJoystick::PollDevice() Quitting\n"); return false; // First set immediate direction if your only interested in basic movement if ( m_dijs.lX < 0 ) m_JoyLeft=true; else m_JoyLeft=false; if ( m_dijs.lX > 0 ) m_JoyRight=true; else m_JoyRight=false; if ( m_dijs.lY < 0 ) m_JoyUp=true; else m_JoyUp=false; if ( m_dijs.lY > 0 ) m_JoyDown=true; else m_JoyDown=false; m_JoyFire1=false; #ifdef _DEBUG int firecount=0; #endif for(int i=0;i<sizeof(m_dijs.rgbButtons);i++) if(m_dijs.rgbButtons[i]&0x80) #ifdef _DEBUG firecount++; #endif m_JoyFire[i]=true; m_JoyFire1=true; else m_JoyFire[i]=false;



#ifdef _DEBUG if(firecount>0) OutputDebugString("Many Buttons Pressed\n"); #endif return true; ////////////////////////////////////////////////////////////////////// // // Run the joystick Control Panel! // ////////////////////////////////////////////////////////////////////// void CDIJoystick::RunControlPanel() if(!m_lpDI) return; m_lpDI->RunControlPanel(m_hwnd,NULL);

10.2.2 MeteorControl.cpp // MeteorControl.cpp : Defines the class behaviors for the application. // // Author : Jennifer Indovina // // Date Created : 9/10/2005 // // Last Modified : 10/31/2005 // #include "stdafx.h" #include "MeteorControl.h" #include "MeteorControlDlg.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CMeteorControlApp BEGIN_MESSAGE_MAP(CMeteorControlApp, CWinApp)



//AFX_MSG_MAP(CMeteorControlApp) // NOTE - the ClassWizard will add and remove mapping macros here. // DO NOT EDIT what you see in these blocks of generated code! //AFX_MSG ON_COMMAND(ID_HELP, CWinApp::OnHelp) END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CMeteorControlApp construction CMeteorControlApp::CMeteorControlApp() // TODO: add construction code here, // Place all significant initialization in InitInstance ///////////////////////////////////////////////////////////////////////////// // The one and only CMeteorControlApp object CMeteorControlApp theApp; ///////////////////////////////////////////////////////////////////////////// // CMeteorControlApp initialization BOOL CMeteorControlApp::InitInstance() AfxEnableControlContainer(); // Standard initialization // If you are not using these features and wish to reduce the size // of your final executable, you should remove from the following // the specific initialization routines you do not need. CMeteorControlDlg dlg; m_pMainWnd = &dlg; int nResponse = dlg.DoModal(); if (nResponse == IDOK) // TODO: Place code here to handle when the dialog is // dismissed with OK else if (nResponse == IDCANCEL) // TODO: Place code here to handle when the dialog is



// dismissed with Cancel // Since the dialog has been closed, return FALSE so that we exit the // application, rather than start the application's message pump. return FALSE;

10.2.3 MeteorControl.h // MeteorControl.h : main header file for the METEORCONTROL application // // Author : Jennifer Indovina // // Date Created : 9/10/2005 // // Last Modified : 10/31/2005 // #if !defined(AFX_METEORCONTROL_H__9AFD07A8_208A_46F3_A723_0E4F302656EA__INCLUDED_) #define AFX_METEORCONTROL_H__9AFD07A8_208A_46F3_A723_0E4F302656EA__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 #ifndef __AFXWIN_H__ #error include 'stdafx.h' before including this file for PCH #endif #include "resource.h" // main symbols ///////////////////////////////////////////////////////////////////////////// // CMeteorControlApp: // See MeteorControl.cpp for the implementation of this class // class CMeteorControlApp : public CWinApp public: CMeteorControlApp();



// Overrides // ClassWizard generated virtual function overrides //AFX_VIRTUAL(CMeteorControlApp) public: virtual BOOL InitInstance(); //AFX_VIRTUAL // Implementation //AFX_MSG(CMeteorControlApp) // NOTE - the ClassWizard will add and remove member functions here. // DO NOT EDIT what you see in these blocks of generated code ! //AFX_MSG DECLARE_MESSAGE_MAP() ; ///////////////////////////////////////////////////////////////////////////// //AFX_INSERT_LOCATION // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_METEORCONTROL_H__9AFD07A8_208A_46F3_A723_0E4F302656EA__INCLUDED_)

10.2.4 MeteorControlDlg.cpp // MeteorControl.h : main header file for the METEORCONTROL application // // Author : Jennifer Indovina // // Date Created : 9/10/2005 // // Last Modified : 10/31/2005 // #if !defined(AFX_METEORCONTROL_H__9AFD07A8_208A_46F3_A723_0E4F302656EA__INCLUDED_) #define AFX_METEORCONTROL_H__9AFD07A8_208A_46F3_A723_0E4F302656EA__INCLUDED_ #if _MSC_VER > 1000



#pragma once #endif // _MSC_VER > 1000 #ifndef __AFXWIN_H__ #error include 'stdafx.h' before including this file for PCH #endif #include "resource.h" // main symbols ///////////////////////////////////////////////////////////////////////////// // CMeteorControlApp: // See MeteorControl.cpp for the implementation of this class // class CMeteorControlApp : public CWinApp public: CMeteorControlApp(); // Overrides // ClassWizard generated virtual function overrides //AFX_VIRTUAL(CMeteorControlApp) public: virtual BOOL InitInstance(); //AFX_VIRTUAL // Implementation //AFX_MSG(CMeteorControlApp) // NOTE - the ClassWizard will add and remove member functions here. // DO NOT EDIT what you see in these blocks of generated code ! //AFX_MSG DECLARE_MESSAGE_MAP() ; ///////////////////////////////////////////////////////////////////////////// //AFX_INSERT_LOCATION // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_METEORCONTROL_H__9AFD07A8_208A_46F3_A723_0E4F302656EA__INCLUDED_)



10.2.5 MeteorControlDlg.h // MeteorControlDlg.h : header file // // Author : Jennifer Indovina // // Date Created : 9/10/2005 // // Last Modified : 10/31/2005 // #if !defined(AFX_METEORCONTROLDLG_H__53AA2313_BBB5_4D9D_AD57_0975B0CBBD49__INCLUDED_) #define AFX_METEORCONTROLDLG_H__53AA2313_BBB5_4D9D_AD57_0975B0CBBD49__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 #include "DIJoystick.h" ///////////////////////////////////////////////////////////////////////////// // CMeteorControlDlg dialog class CMeteorControlDlg : public CDialog // Construction public: CMeteorControlDlg(CWnd* pParent = NULL); // standard constructor // Dialog Data //AFX_DATA(CMeteorControlDlg) enum IDD = IDD_METEORCONTROL_DIALOG ; // NOTE: the ClassWizard will add data members here CComboBox m_ctlButtonNames; CComboBox m_ctlJoystickName; BOOL m_Down; BOOL m_Fire; BOOL m_Left; BOOL m_Right; BOOL m_Up; CString m_XAxis; CString m_YAxis;



CString m_ZAxis; CString m_FireText; CString m_RXAxis; CString m_RYAxis; CString m_RZAxis; //AFX_DATA // ClassWizard generated virtual function overrides //AFX_VIRTUAL(CMeteorControlDlg) protected: virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support //AFX_VIRTUAL // Implementation protected: HICON m_hIcon; // Generated message map functions //AFX_MSG(CMeteorControlDlg) virtual BOOL OnInitDialog(); afx_msg void OnSysCommand(UINT nID, LPARAM lParam); afx_msg void OnPaint(); afx_msg HCURSOR OnQueryDragIcon(); afx_msg void OnSelchangeButtonNames(); virtual void OnCancel(); afx_msg void OnButton1(); afx_msg void OnTimer(UINT nIDEvent); afx_msg void OnSelchangeJoystickName(); //AFX_MSG DECLARE_MESSAGE_MAP() public: int m_Buttons; // how many buttons does the device have? ; extern CDIJoystick myJoystick1; //AFX_INSERT_LOCATION // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_METEORCONTROLDLG_H__53AA2313_BBB5_4D9D_AD57_0975B0CBBD49__INCLUDED_)



10.3 Bill of Materials (per launch)

Bill of Materials (BOM)

Quantity

Supplier

Part N

umber

Description

Price/U

nit

Total Cost

Order = 0

Inventory = I M

ake = M

Ordered = X

R

eceived = R

1universal-radio.com KPC-3 Plus Terminal Node Controller 189.95 189.95 O R

2universal-radio.com M-24M Cornet - Mobile Dual Band Antenna 37.95 75.90 O R

2universal-radio.com MFG-1702C MJF - Antenna Switch (2 position) 22.95 45.90 O R

1universal-radio.com FT-7800R 2m/440cm Communication Radio 249.95 249.95 O R

10 DigiKey 367-1037-ND PL-259 to RG-58 Connector Male 1.03 10.30 O R1 DigiKey A305-100-ND RG-58 Cable 100 ft 45.40 45.40 O R1 DigiKey WM5782-ND Terminal Strip/Barrier Block 5.57 5.57 O R2 DigiKey LM35CAZ-ND Analog Temperature Sensor 5.40 10.80 O R

2 DigiKey2SD24570QL

CT-ND Replacement for 440 Transmitter 0.94 1.88 O R10 DigiKey 67-1103-ND RED LED 2.63 26.30 O R10 DigiKey P330ACT-ND 330 Ohm drop RES 0.77 7.70 O R10 DigiKey P220ACT-ND 220 Ohm drop RES 0.77 7.70 O R

10 DigiKeyPCC1858CT-

ND 0.01 uF Cap 0.44 4.40 O R


ND 1 uF Cap 0.72 7.20 O R


ND 470 pF Cap 0.66 6.60 O R

Lowes Wood Supplies for 'Mobile Rig' 50.00 50.00 O R

2 Tigerdirect.com M501-1000 USB - Serial Adapter 9.99 19.98 O R

2LaptopPartsNow.

com Quantex TS201 Automotive Car Airline DC Adapter 52.95 105.90 O R

http://store.yahoo.com/laptoppartsnow/pncac100542.html2 Kaymont KCI 1500 O R

2 Dinsmore Sensor 1490 Digital Sensor 13.00 26.00 O R

1 Dinsmore Sensor 1525 Analog Sensor 37.00 37.00 O R

1 Dinsmore Sensor R1655 Analog Sensor 37.00 37.00 O R

1 Express PCB RXLY3573 PIC1 Express PCB VAUC35740 Flashing LED

20 BatteryMart.com BAT-U9VL-X 9 Volt Lithium Ultra Life Batteries 5.20 104.00 O R



10.4 Quality Function Deployment Michael Giannotti

Flig

ht D

urat

ion

will

last

at l

east

~3

hour

s

Batte

ry L

ife w

ill la

st ~

15

hour

s

Gro

und

Con

trol T

rans

mis

sion

sha

ll ha

ve a

rang

e of

~10

0 m

iles

Pla

tform

Pow

er s

ourc

e sh

all b

e ab

le to

sup

port

amp-

hour

s fo

r 20

hour

s

Plat

form

will

be a

ble

to d

eter

min

e in

stan

tane

ous

plat

form

sp

eed

(sam

ple

ever

y 30

sec

onds

)

Plat

form

will

cont

inuo

usly

con

sum

e ~3

00 m

a fo

r 15

hour

s

Bat

tery

con

sum

ptio

n w

ill be

less

than

x a

mp-

min

s

All a

nalo

g da

ta w

ill be

con

verte

d to

dig

ital w

ith x

reso

lutio

n an

d sa

mpl

ed e

very

x m

sec

Plat

form

sha

ll tra

nsm

it au

dibl

e an

d vi

sibl

e la

ndin

g po

sitio

n fo

r 100

mile

s

Mot

or C

ontro

ller w

ill ne

ed to

sup

ply

pow

er a

t x m

illiam

ps to

a

mot

or a

t 1x

RP

Ms

Plat

form

will

be a

ble

to s

tore

1 k

byte

s of

dat

a if

data

tra

nsm

issi

on is

lost

Pla

tform

sha

ll tra

nsm

it w

hen

the

plat

form

mem

ory

buffe

r be

com

es 9

0% fu

ll

Platform shall remain powered and functional for the duration of the flight 9 2 6 2 0 5 2 6 2 0 4Platform shall be able to reach height and land 0 0 0 0 0 5 0 0 0 0 3Balloon and platform shall be able to reposition itself for a safe re-entry and landing 0 7 3 7 5 5 7 3 7 5 5Platform shall warn pedestrians upon re-entry 0 9 0 9 0 1 9 0 9 0 0

Platform shall disclose its position throughout the flight, re-entry and on ground 2 9 8 9 0 0 9 8 9 0 5

METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 7 0 7 1 4 7 0 7 1 4Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 4 7 8 3 3 4Ground Station will be able to transmit commands to Platform 4 7 8 8 0 5 7 8 8 0 5

Platform will be able to transmit to Ground Station real time video and digital data 4 7 9 8 3 5 7 9 8 3 5

Platform electronics will apply standard interface protocols (i.e. USB) 4 7 6 8 1 0 7 6 8 1 0

Platform will ensure reliable operation and apply redundant circuitry where necessary 0 7 6 8 0 0 7 6 8 0 0Platform shall store critical flight telemetry data until data transmission occurs 0 9 9 8 4 2 9 9 8 4 9Platform shall transmit all flight data 9 9 9 8 0 5 9 9 8 0 9Platform shall operate autonomously if communications with Ground Station is lost 4 7 1 8 0 5 7 1 8 0 5Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 0 4 0 0 0 0 4Platform will illuminate during re-entry 5 9 0 8 0 3 9 0 8 0 3Platform shall be reusable 9 3 0 0 0 0 3 0 0 0 0Non-integrated beacon sucessful in platform retrieval 5 0 7 5 0 0 0 7 5 0 2

Specifications

96

86

6

0

56

8

5

5

99

94705



Rina Matoba

Flig

ht D

urat

ion

will

last

at l

east

~3

hour

s

Bat

tery

Life

will

last

~ 1

5 ho

urs

Gro

und

Con

trol T

rans

mis

sion

sha

ll ha

ve a

rang

e of

~10

0 m

iles

Pla

tform

Pow

er s

ourc

e sh

all b

e ab

le to

sup

port

amp-

hour

s fo

r 20

hour

s

Pla

tform

will

be

able

to d

eter

min

e in

stan

tane

ous

plat

form

sp

eed

(sam

ple

ever

y 30

sec

onds

)

Sim

ulat

ion

resu

lts to

impa

ct d

esig

n

Tem

pera

ture

of e

lect

roni

cs s

hall

not e

xcee

d x

degr

ees

Def

ine

fligh

t the

rmo

sens

ors

to m

onito

r and

trac

k

Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 9 9Ground Station will be able to transmit commands to Platform 4 7 8 8 0 0 0Platform will be able to transmit to Ground Station real time video and digital data 4 7 9 8 3 0 0Platform shall store critical flight telemetry data until data transmission occurs 0 9 9 8 4 0 0Platform shall transmit all flight data 9 9 9 8 0 8 9Platform shall operate autonomously if communications with Ground Station is lost 4 7 1 8 0Platform shall be reusable 9 3 0 0 0 0 0Thermo-characteristics will be modeled during design and then measured during flight. 6 6 7 8 1 9 9

Platform positioning efficiency will modeled during design and then measured during flight. 6 9 7 8 1 0 0

Power consumption will modeled during design and then measured during flight. 6 9 7 8 0 0 0Radiation (i.e. heat build-up) will be measured during flight. 6 9 7 8 0 8 8Temperature Sensor monitoring internal and external temperatures (~20 C) 6 9 7 8 0 7 9

Specifications

80

0

07

0

9

0

08

8



Jennifer Indovina

Flig

ht D

urat

ion

will

last

at l

east

~3

hour

s

Gro

und

Con

trol T

rans

mis

sion

sha

ll ha

ve a

rang

e of

~10

0 m

iles

Pla

tform

will

be

able

to d

eter

min

e in

stan

tane

ous

plat

form

sp

eed

(sam

ple

ever

y 30

sec

onds

)

Pla

tform

sha

ll tra

nsm

it au

dibl

e an

d vi

sibl

e la

ndin

g po

sitio

n fo

r 100

mile

s

Pla

tform

will

be

able

to s

tore

1 k

byte

s of

dat

a if

data

tra

nsm

issi

on is

lost

Pla

tform

sha

ll tra

nsm

it w

hen

the

plat

form

mem

ory

buffe

r be

com

es 9

0% fu

ll

Pla

tform

sha

ll tra

nsm

it its

land

ing

with

in 2

0 m

eter

s fo

r 100

m

eter

dis

tanc

e

Pla

tform

sha

ll be

retri

evab

le o

n an

y te

rrai

n or

alti

tude

Gro

und

Con

trol s

oftw

are

- GU

I, flo

wch

art,

tele

met

ry d

ispl

ay,

and

long

term

sto

rage

Gro

und

cont

rol t

rans

mis

sion

sha

ll ha

ve a

rang

e of

x m

iles

Pla

tform

sha

ll tra

nsm

it ev

ery

~30

seco

nds

Platform shall remain powered and functional for the duration of the flight 9 6 0 2 4 9 5 0 3 3Platform shall be able to reach height and land 0 0 0 0 3 6 0 0 9 8Balloon and platform shall be able to reposition itself for a safe re-entry and landing 0 3 5 7 5 8 0 0 6 4Platform shall warn pedestrians upon re-entry 0 0 0 9 0 6 0 0 0 5Platform shall disclose its position throughout the flight, re-entry and on ground 2 8 0 9 5 6 9 9 8 3

METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 0 1 7 4 0 0 8 7 8Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 8 3 3 4 5 0 0 7 9

Ground Station will be able to transmit commands to Platform 4 8 0 8 5 6 0 0 9 5Platform will be able to transmit to Ground Station real time video and digital data 4 9 3 8 5 8 0 0 9 5Platform electronics will apply standard interface protocols (i.e. USB) 4 6 1 8 0 5 0 0 9 5

Platform will ensure reliable operation and apply redundant circuitry where necessary 0 6 0 8 0 5 2 0 0 0

Platform shall store critical flight telemetry data until data transmission occurs 0 9 4 8 9 9 0 0 6 3Platform shall transmit all flight data 9 9 0 8 9 9 0 0 8 4Platform shall operate autonomously if communications with Ground Station is lost 4 1 0 8 5 9 0 0 0 5Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 4 4 0 0 0 0Platform will illuminate during re-entry 5 0 0 8 3 7 0 0 0 0Platform positioning efficiency will modeled during design and then measured during flight. 6 7 1 8 2 2 0 0 9 7Non-integrated beacon sucessful in platform retrieval 5 7 0 5 2 5 0 0 0 0Define other data gathering sensors or experiments. 3 0 0 0 0 5 0 0 0 0Pre-flight Ground Station operator 0 3 0 3 9 0 0 0 9 9Flight Ground Station operator 4 3 0 3 9 5 0 0 9 8Post-flight Ground Station operator 4 3 0 3 6 0 0 7 9 9Ground Station data server Analyst 4 3 0 3 6 6 0 0 9 8pedestrians at landing zone 0 0 0 0 2 0 6 0 4 0Land owner at landing zone 0 0 0 0 2 0 0 0 1 0Chasers 4 0 0 0 5 0 6 0 1 3FAA Analyst (if pre-flight approval is needed) 0 0 0 0 0 0 0 0 1 0Equipment Transporters 0 0 0 0 6 0 0 0 1 0Equipment operators, maintained 0 0 0 0 6 0 0 0 0 0

Specifications

56

24

9

7

9

9

8

8

0

77

000

7004444000200



Richard Paasch

Flig

ht D

urat

ion

will

last

at l

east

~3

hour

s

Bat

tery

Life

will

last

~ 1

5 ho

urs

Gro

und

Con

trol T

rans

mis

sion

sha

ll ha

ve a

rang

e of

~1

00 m

iles

Pla

tform

Pow

er s

ourc

e sh

all b

e ab

le to

sup

port

amp-

hour

s fo

r 20

hour

s

Pla

tform

will

be

able

to d

eter

min

e in

stan

tane

ous

plat

form

spe

ed (s

ampl

e ev

ery

30 s

econ

ds)

Pla

tform

sha

ll be

abl

e to

mov

e/re

posi

tion

itsel

f with

in

0.5

met

ers

of m

ax h

eigh

t

Mot

or p

ower

con

sum

ptio

n w

ill b

e 5

mill

iam

ps fo

r no

mor

e th

an m

ax. f

light

dur

atio

n

Mot

or p

ower

sha

ll be

sup

plie

d by

bat

terie

s

Pla

tform

sha

ll by

abl

e to

repo

sitio

n in

self

with

in 0

.5

met

ers

Pla

tform

sha

ll be

abl

e to

pos

ition

itse

lf us

ing

prop

elle

rs

with

a m

inim

um s

peed

of 1

0 m

/sec

for 1

20 m

ins

Pla

tform

will

with

stan

d la

ndin

g ve

loci

ty o

f x m

/sec

Pla

tform

sha

ll be

retri

evab

le o

n an

y te

rrai

n or

alti

tude

Platform shall remain powered and functional for the duration of the flight 9 2 6 2 0 0 9 9 0 0 0Balloon and platform shall be able to reposition itself for a safe re-entry and landing 0 7 3 7 5 7 0 0 7 9 0

METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 7 0 7 1 0 0 0 0 0 9Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 0 0 0 0 0 0Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 0 0 0 7 0 0 7Platform shall be reusable 9 3 0 0 0 0 0 7 0 0 0Platform positioning efficiency will modeled during design and then measured during flight. 6 9 7 8 1 9 7 7 9 9 0Power consumption will modeled during design and then measured during flight. 6 9 7 8 0 7 9 9 7 7 0Non-integrated beacon sucessful in platform retrieval 5 0 7 5 0 0 0 0 0 0 0Pre-flight Ground Station operator 0 3 3 3 0 0 5 0 0 0 0Flight Ground Station operator 4 3 3 3 0 9 0 0 9 9 0Post-flight Ground Station operator 4 3 3 3 0 0 0 0 0 0 5Ground Station data server Analyst 4 3 3 3 0 0 0 0 0 0 0

Specifications

0

0

8

000

0

000070



Vivek Shah

0

90

90

0

09

00090

0

0920000

Specifications

Flig

ht D

urat

ion

will

last

at l

east

~3

hour

s

Bat

tery

Life

will

last

~ 1

5 ho

urs

Gro

und

Con

trol T

rans

mis

sion

sha

ll ha

ve a

rang

e of

~1

00 m

iles

Pla

tform

Pow

er s

ourc

e sh

all b

e ab

le to

sup

port

amp-

hour

s fo

r 20

hour

s

Pla

tform

will

be

able

to d

eter

min

e in

stan

tane

ous

plat

form

spe

ed (s

ampl

e ev

ery

30 s

econ

ds)

Pla

tform

sha

ll tra

nsm

it its

land

ing

with

in 2

0 m

eter

s fo

r 10

0 m

eter

dis

tanc

e

GP

S d

ata

gath

erin

g, s

tora

ge, a

nd tr

ansm

issi

on,

seco

ndar

y

LED

Fla

shin

g C

ircui

try/T

empe

ratu

re S

enso

r/Com

pass

OS

D-G

PS

Tex

t ove

rlay

METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 7 0 7 1 0 0 0Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 0 5 0Ground Station will be able to transmit commands to Platform 4 7 8 8 0 0 0 0Platform will be able to transmit to Ground Station real time video and digital data 4 7 9 8 3 0 0 0Platform electronics will apply standard interface protocols (i.e. USB) 4 7 6 8 1 0 0 0

Platform will ensure reliable operation and apply redundant circuitry where necessary 0 7 6 8 0 2 9 0Platform shall store critical flight telemetry data until data transmission occurs 0 9 9 8 4 0 9 0Platform shall transmit all flight data 9 9 9 8 0 0 0 5Platform shall operate autonomously if communications with Ground Station is lost 4 7 1 8 0 0 9 9Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 0 0 2 0Platform will illuminate during re-entry 5 9 0 8 0 0 0 9Platform shall be reusable 9 3 0 0 0 0 0 9during flight. 6 6 7 8 1 0 0 0Platform positioning efficiency will modeled during design and then measured during flight. 6 9 7 8 1 0 6 0Power consumption will modeled during design and then measured during flight. 6 9 7 8 0 0 0 0Non-integrated beacon sucessful in platform retrieval 5 0 7 5 0 0 0 0Define other data gathering sensors or experiments. 3 0 0 0 0 0 0 7Pre-flight Ground Station operator 0 3 3 3 0 0 0 0Flight Ground Station operator 4 3 3 3 0 0 0 0Post-flight Ground Station operator 4 3 3 3 0 0 0 0Ground Station data server Analyst 4 3 3 3 0 0 0 0



10.5 Pugh Charts

ual C++ .NET Pugh Analysis

CriteriaImportance


Visual C++ Studio .NET JAVA

Visual Basic IDE

Purchase Cost 7 0.1061 0.1061 0.1061 0.1061Operating Cost 7 0.1061 0.1061 0.1061 0.1061Cycle Time 10 0.1515 0.1515 0.0606 0.0303Mean time between failures 7 0.1061 0.1212 0.0909 0.1364Operating Time 10 0.1515 0.1515 0.0758 0.1061Constant operation 4 0.0606 0.0606 0.0758 0.0303


Vis

OSD System Pugh Analysis

CriteriaImportance


Video Amplifier

OSDµC with

OSDOSD Video Generator

Purchase Cost 10 0.1493 0.1493 0.0746 0.0299Operating Cost 5 0.0746 0.0746 0.0896 0.0746Response Time 4 0.0597 0.0448 0.0597 0.0597Failure Time 10 0.1493 0.1343 0.1493 0.1343Operating Time 5 0.0746 0.0448 0.0597 0.0746Constant operation 10 0.1493 0.1493 0.1493 0.1493




Single Propeller Design Pugh Analysis

CriteriaImportance


Single Propeller

Gas Turbine

Purchase Cost 8 0.1096 0.0959 0.0959Operating Cost 7 0.0959 0.0959 0.0959Response Time 10 0.1370 0.1370 0.0548Failure Time 9 0.1233 0.1096 0.0822Operating Time 10 0.1370 0.1370 0.0685Constant operation 8 0.1096 0.0548 0.0685Mean Time to repair 7 0.0959 0.0822 0.0411Current system compatibility 10 0.1370 0.1370 0.1096Startup time 4 0.0548 0.0411 0.0137Best Option based on weighted Criteria 1.0000 0.8904 0.6301

Thermal Model Pugh Analysis

CriteriaImportance

RankingWeighted Ranking ANSYS ProE

System Stability 8 0.1290 0.1129 0.1129Ease of Use 7 0.1129 0.1129 0.1129Thermal Modeling Capability 10 0.1613 0.1613 0.0645Thermal Model 9 0.1452 0.1290 0.0968Correct results 10 0.1613 0.1613 0.0806Constant operation 8 0.1290 0.0645 0.0806

Mean Time to repair 7 0.1129 0.0968 0.0484Current system compatibility 1 0.0161 0.0161 0.1290Startup time 2 0.0323 0.0323 0.0161Best Option based on weighted Criteria 1.0000 0.8871 0.7419



10.6 Gantt Charts

Week 6 Week 7 Week 8 Week 9 Week 10Mike Code Reasearch METEOR 3 Launch METEOR 2005 Research PDR

CANCELLED Code ReasearchPeer Review

Vivek GPS research METEOR 3 Launch PDRCANCELLED 70cm Tx Research

Peer ReviewJennifer Basic GUI base METEOR 3 Launch Continue designing window PDR

Joystick and axis map CANCELLED Joystick applicationPeer Review

Rina Software research METEOR 3 Launch PDRTemperature Modeling CANCELLED Temperature ModelingPeer Review

Rich Determine reqs METEOR 3 Launch PDRfor propellor design CANCELLED Rotor Software SearchPeer Review

Fall 2005

Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10Mike Team Add code to software to integrate Verify

Meeting GUI, joystick, propeller motor, backup GPS PDRChanges

Vivek Team VerifyMeeting Update Documentation for PDR PDR

PCB Express Layout/Board Redesign ChangesJennifer Team Verify

Meeting Redo PDR Documentation PDRChanges

Rina Team VerifyMeeting Review new software PDR

ChangesRich Team Verify

Meeting Learn XROTOR Software PDRChanges

Winter 2005



Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10Mike Continue integration Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Results

Launch Repair Platform Launch Documentation CDRAssist w/ assembly Rebuild Platform

Vivek Begin assembly Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Resultsof platform for launch Launch Repair Platform Launch Documentation CDR

Rebuild PlatformJennifer Integrate software Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Results

with ACS Launch Rebuild Platform Launch Documentation CDRAssist w/ assembly

Rina Testing METEOR 3 Document Temp Data Testing METEOR 4 Review ResultsFluent / MATLAB Launch ANSYS Thermal Modeling Launch Documentation CDR

Rich Review software and Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Resultstest with motors Launch Rebuild Platform Launch Documentation CDRAssist w/ assembly

Spring 2005



10.7 Functional Diagrams Diagram of OSD Functionality: Diagram of ACS:

InitializationPower Up Reset

Get Heading

Get Acceleration

Clear WDT

ScreenCount Done?

Reset OSD Template Screen

1 0

iAPRSLoopCount Done?

Send APRS Packet to TNC

1 0

Current Video Camera Counter

Done?

Roll Video Camera

1 0

Create OSD Template Screen

ScreenCount = 0

iAPRSLoopCount = 0

iCameraLoopCount = 0

igetDataCounter Done?

1 0

igetDataCounter = 0

Get Pressure

Get Temperature

Get GPS

Update OSD

Increment Counters

Print Heading onto OSD

Print Acceleration onto OSD



10.8 System Diagram

Motor

Actuator(Propeller)

70-cm Tx439.25 MHz

Video Overlay

Video Camera 1

GPS(Harris)

2 Internal Temp

Sensors

Pressure Sensor

3 Accelerometers

Digital Compass

RS232

/ 2Analog

TTL

RS232

Analog

/ 3Analog

Beacon

MAX232(RS232 Driver)

TTL

RS232

RS232

VIDEO MUX

Video Camera 2

Video Camera 3

Video Camera 4

DUAL UART MUX

TTL TTL

PIC

ADC

/ 3Select Lines

/ 3Select Lines

DEMUX

Power Control

2-m Tx/Rx

RTS Signal

TTL

/ 2Analog

2 External Temp

Sensors

TNCDuplexer

Analog Compass

Composite

Digital Compass

/ 4N S E W

Analog

Composite

Composite

Composite

Composite

/ 3Select Lines

GPS(Tyco)

FM Tx144.39 MHz

RS232 Driver

TTL

RS232

TNC

Tones

TTL

Driver(Joystick

Coordinates from 2-m Tx/Rx to PIC)

Photovoltaic Cells,

DC to DC Converter



10.9 Launch Preparation Diagram




Documents

RITedge.rit.edu/content/P07109/public/Admin Files...Project 20006: Yaw controlled, balloon tethered platform for METEOR Project 2005/2006 Team Michael Giannotti (EE) – Rina Matoba