P17104: HABIP-COMMS
/public/

Preliminary Detailed Design

Table of Contents

Team Vision for Preliminary Detailed Design Phase

Goals for this Phase:

Accomplishments

High Level System Block Diagram

High Level System Block Diagram

High Level System Block Diagram

Feasibility: Prototyping, Engineering Analysis, Simulation

We are continuing to develop our concepts and analyze the feasibility of them.

Platform Design and Prototyping

Preliminary Development

First generation concept prototype comes from the "Disk" concept generated in previous phases. The disk geometry allows for a reduced height profile and increased inertia. This was deemed most beneficial for several reasons. The first of which being that while at high altitudes (excess of 60,000 ft) an increase inertia will serve to maintain system stability, leading to a decrease in the requirements of the Reaction Wheel. With the decreased height profile more components are required to be placed radially, one a select number of surfaces decreasing the overall unused surface area, decreasing weight. In comparison to the alternative "Pill" concept, the "Disk" offers an 80% increase in the effective surface area to weight ratio. This aspect is crucial in design going forward.

Platform Enclosure

Platform Enclosure

From the above figure it can be seen the structure itself is a composite of concentric rings and plates as to maintain ease of development, analysis, and replication. The base material of the structure is polystyrene insulation board. This material was chosen based on two key aspects - weight and cost. The board is lightweight while affording enough [projected] support in the event of impact (as it is compressible due to material porosity). Coupling of the individual layers will be accomplished using threaded rods radially placed around the perimeter of the structure as shown previously. The rods will be fasten in using bolt connections in order to maintain system modularity.

Concept Development and Production

Initial prototyping is being accomplished through use of store bought materials and simple tooling procedures/devices. A plan for future manufacturing/development has already been confirmed through the "Construct", mainly utilizing a CNC Router.

Critical Component Interfacing Plan

Critical Component Interfacing Plan

There are no anticipated setbacks in terms of manufacturing feasibility as the CNC feasibility has already been confirmed and even should there be an issue, initial prototyping methods (hand working) can be used. This statement however does not mean that there are no issues related to development. The following highlights issues already apparent with prototyping.

Development Progression and Issues

Development Progression and Issues

Component Position and Energy Control

Additional structural components will be added in order to assist in critical functional areas such as temperature. The structural design was developed with passive energy mitigation in mind. For example the platform utilizes rings instead of complete plates as to place components as close to the outside walls as possible, decreasing the time response of the system.

Component Positions

Component Positions

Among the critical energy control elements are the ATV Transceiver and Reaction Wheel Motor. The ATV Transceiver is located on the bottom face of the inside of the HAB while the motor is placed atop the HAB. It is necessary for the both components to transfer enough energy as to remain in their operational temperature ranges, however the control method cannot contribute an excessive amount of additional weight. For this purpose active mitigation such as thermoelectic coolers are only considered as a last resort. Instead physical conductive pathways will lead from the components to the bottom of the HAB where the energy will be bleed off by both convection and radiation.

Critical Component Interfacing Plan

Critical Component Interfacing Plan

Bottom face thermal control is absolutely necessary to ensure component health, however it is a very complicated issue. The HAB is constantly ascending/descending - never reaching an equilibrium with the apparent atmosphere. As such FEA software is [for the most part] useless. This situation however requires a composite dynamic modeling cycle along with test data. Acquiring test data too is problematic as an Altitude Chamber (Combined depressurization and temperature control) is not readily available for use. This constitutes a high risk item for HAB development. The dynamic modeling of the system is highly dependent on the geometry, material selection, environmental variation, etc... In trying to determine capability requirements that are necessary in order to permit such a system architecture as outlined in the "Component Placement Plan" Figurea handful of loading scenarios were examined. The two of most [current] significant value are the validation of bottom face factors and bottom face maximum performance.

Energy Cycle Comparisons

Energy Cycle Comparisons

From the above figure it can be seen that if the transceiver (which outputs from 0-5W) it can be seen that just suspending the transceiver in the environment, while outputting at 1W, results in the high temperature boundary (of the transceiver) being exceeded at around the 6000 seconds mark into the flight. This is a hard confirmation that additional management systems are required so that the system components are not in danger of failure. With this being the case, considering the structure architecture, it makes logical sense to place additional dissipating elements at locations where power generation is most concentrated - namely the top and bottom of the HAB Platform. The bottom surface is an excellent choice as since the surface is not normal to solar rays, permits radiation heat transfer in additional to forced convection from the flight. To analyze the effects of extending the heat dissipation system to the bottom surface an additional simulation was run incorporating the effects, yielding the second figure of the diagram. Using this architecture, the system could roughly dissipate 35 Watts of heat, more than 35 times the heat that the original system could mitigate. Thus this architectural setup will be the focus of the next phase. Additional design priorities of the next phase will include dissipation network design, time constant optimization, and finalized power input figures.

Analog Video Overlay

Using analog TV, a live video feed captured by NTSC cameras mounted to the platform will be transmitted back to the base station. Along with the image, text will be overlaid upon the live video to convey telemetry and other data including but not limited to:

The analog overlay board being used is the OSD-232 from Intuitive Circuits. Its input will be the video stream from the video multiplexer, as well as an RS-232 interface with the COMMS controller.

The main COMMS controller will be communicating with the DAQCS controller via a SPI interface to retrieve the sensor data. Once this data is received from the DAQCS controller it will properly format the data and update the overlay. This will process at some specified interval to continuously update the live video feed with data.

Analog Video Overlay Demo

Analog Video Overlay Demo

View the YouTube video of the OSD demo here.

OSD+ATV Transmitter Prototyping

We received the ATV transmitter that we purchased and got it working. In the METEOR lab, we used the OSD to display data on a video feed and transmit it with the ATV transmitter. We received the signal with an antenna that went into an old CRT TV to display what was sent.

View the YouTube video of the OSD+ATV Transmitter demo here.

Transceiver Prototyping Design Plan

In selecting a 2m transceiver, 3 options were considered:

1. Use a Radiometrix QPX1 as a data transceiver, with tx/rx data presented over a serial interface

2. Use a handheld transceiver, with tx/rx data presented over an Audio (FSK) interface. A Raspberry Pi will run MiniModem to modulate/demodulate these audio signals, using a sound card

3. Using TNC-Pi, a board used in conjunction with a Raspberry Pi to build a TNC (terminal node controller) packet communicator.

Ultimately, option 2 was decided upon. This option will provide for rapid development, as all the interfaces are very well defined (USB, Audio). On the contrary, the TNC-Pi setup will require an understanding of the complex, but powerful, TNC standards. This may provide more functionality than we actually need, and extend development time. The Radiometrix QPX1 was quickly eliminated as an option, because it has poor documentation.

The following image shows the high level system diagram needed to build the 2m data transceiver, using the Raspberry Pi Zero, USB Sound Card, and Baofeng UV5RA radio.

2m Transceiver using Baofeng Radio, USB Sound Card, and Raspberry Pi

2m Transceiver using Baofeng Radio, USB Sound Card, and Raspberry Pi

The Raspberry Pi will be running an open source software called MiniModem, in two separate threads. One thread will handle receiving data from the Baofeng Radio; the other will handle transmitting data to the Baofeng Radio.

Minimodem uses FSK (Frequency Shift Keying) to modulate and demodulate digital data as audio, and vice versa. A USB sound card will be used to transmit and receive this data as audio.

With audio going out in both directions between the Baofeng radio and the USB sound card, through the audio out/mic in ports of each device, a bidirectional communication link has now been developed. Any digital data that needs to reach the Raspberry Pi in the HAB from the base station will be modulated into audio at Mission Control using MiniModem, and transmitted over 2m. The Baofeng radio will then receive this audio, and output it to the Raspberry Pi. The audio will be demodulated to digital data on the Raspberry Pi, using MiniModem in conjunction with the USB sound card.

If the Raspberry Pi wishes to reply with data, it must only use MiniModem to modulate this data into Audio over the sound card. The Baofeng radio, when Push to Talk is operated (controlled via GPIO), will transmit this modulated data over the 2m band, where it can be received by the base station.

We did a loop-back test with MiniModem running on a Raspberry Pi with the USB sound card at 1200 bps. It fully worked.

Raspberry Pi Zero for Entire Communication Subsystem

We need to use a Raspberry Pi Zero for the above transceiver approach. After careful thought, we realized it has the interface support to be the only controller for the communication subsystem.

The Raspberry Pi Zero has 2x SPI, 1x UART, and 1x I2C interfaces available (in addition to GPIO).

Our Interfaces:

The Raspberry Pi Zero can cover all of the above interfaces.

Power Analysis

We have created a more detailed power analysis for the communication subsystem.
COMMS Power

COMMS Power

We split up the power between the ATV transmission side and the rest of the communication subsystem in case the ATV transmitter drained its battery source. The analog video cameras, OSD, video mux, and ATV transmitter are on a single supply. The Raspberry Pi Zero, redundant GPS, transceiver radio, and temperature sensor are on a separate supply. The APRS also has its own battery supply so that it is completely independent from everything else. Power management will be done on the custom PCB board. We used TI's WEBENCH tool to determine power management solutions.

7.4V Battery Supply

7.4V Battery Supply

A 7.4V battery will be used to power the Raspberry Pi Zero, redundant GPS, transceiver radio, and temperature sensor. Using the WEBENCH tool, it was found that the other Pi, GPS, and temperature sensor need 0.15A from the battery. Assuming the ideal flight duration of 3 hours, 450mAh is needed. Additional mAh are needed for the transceiver's radio. The radio comes with 1800mAh battery. So, we need around 2250mAh for a 7.4V battery. We chose a 7.4V 2600mAh battery.

11.1V Battery Supply

11.1V Battery Supply

An 11.1V battery will be used to power the analog video cameras, OSD, video mux, and ATV transmitter. Using the WEBENCH tool, it was found that 1.47A (1470mA) is needed from the battery. Assuming the ideal flight duration of 3 hours, 4410mAh are needed from an 11.1V battery. We found 4400mAh and 5200mAh 11.1V battery packs with overcharge and over-discharge protection; there is only a 10g difference, so we chose the 5200mAh battery to give us more of a cushion. It will also help if we end up needing more output power from the ATV transmitter.

The working power document can be found here: Power Analysis Spreadsheet

Weight Analysis

We are looking at the communication subsystem being around 4 lbs currently. The DAQCS subsystem is also around 4 lbs. It looks like we will be over the initial goal of <=6 lbs. We are looking into what the procedures and requirements are for a unmanned free balloon over 6 lbs.

The working weight analysis document can be found here: Weight Analysis Spreadsheet

Part Physical Characteristics

Part Physical Characteristics

We have been collecting the physical characteristics of our selected parts. Operating temperature ranges, weight, and dimensions are important.

Weight Analysis

Weight Analysis

The above image shows the weight analysis specifically for the communication subsystem. The weights are color-coded to show which components contribute the most to the overall weight.

Platform Commands

This section includes preliminary lists of commands for the platform. Ground commands will be received from the ground by the communication subsystem. The communication subsystem will also send certain commands to the data acquisition and control (DAQCS) side.

Preliminary Ground Command List

Preliminary List of Commands to the DAQCS Side

Not all of these commands necessarily have ground commands.

Commands to request data:

Command actions:

Custom PCB Board Contents

We are currently planning to only have 1 custom PCB board for the communication subsystem.

As of this time, the custom PCB board will have the following components:

Other than the power management chips, all of the main components for the custom PCB board are in the Bill of Materials (BOM). Other "jelly bean" components still need to be determined. A solution also needs to be determined for the antenna for the GPS module; we are currently thinking about using a chip antenna.

Once the BOM is finalized, an estimate for the size of the custom PCB board can be made, allowing for a price estimate to be made.

The custom PCB board will most likely be 4 layers since there is RF for the GPS module.

Drawings, Schematics, Flow Charts, Simulations

We have started our detailed design. We will continue to revise the design as we progress through the semester and receive feedback from our design review.

Software Design

We will need to develop software coding standards in the next phase.

The diagram below shows the high level software flow for the Raspberry Pi.

High Level Software Flow Diagram

High Level Software Flow Diagram

Power Management Diagram

Power Management Diagram

Power Management Diagram

RF Connections Diagram

The connections from the ATV Transmitter and transceiver to the antenna on the platform are shown below.

RF Connections

RF Connections

Bill of Materials (BOM)

We have created a BOM for the main components of our design. Small, "jelly bean" components" have not been determined at this point.
Bill of Materials

Bill of Materials

The working document can be found here: Bill of Materials Spreadsheet

Part Selection

This section goes into our decisions for the selection of major parts.
Microcontroller
We were originally going to go with a MSP430. However, with our transceiver plan, a Raspberry Pi Zero is needed to run MiniModem on. As seen in the feasibility section, the Raspberry Pi Zero will be able to cover all necessary interfaces for the communications subsystem.
APRS
We chose the Tracksoar device since it is small and open source with software available. We made sure that the call sign is programmable.
Redundant GPS
We chose the Ublox MAX-M8Q since it is used on the Tracksoar APRS device and is easy to use.
Data/Video Overlay Board (OSD)
We were looking at Intuitive Circuit's OSD-232+ board since it has a lot of documentation for interfacing with it. We went with the OSD-232 since we have a board from previous years we can use. It is just an older version of the OSD-232+ that is no longer made.
ATV Transmitter
We did not have many options for ATV Transmitters without having to amplify the output of a low output power device. We went with the VideoLynx VM-70X since it should work off-the-shelf and has adjustable output power.
Duplexer
We went with the MX72H Duplexer since it has been used in past METEOR projects and is in our budget.
Antenna
We were considering the Comet SBB-1 antenna that was used in the past. We decided on the Comet SBB-2 since it has higher gain for only a slight increase in price.
Transceiver
See the earlier transceiver sections on this page for design decisions. We are going with a combination of a Raspberry Pi Zero running MiniModem with a handheld HAM radio.
Structure Frame
Polyethylene was chosen for it's lightweight properties while providing sufficient impact resistance. It can be altered easily, it is cheap, it is readily available, and it serves to insulate the structure during portions of atmospheric flight.
Conductive Frame Work
Chosen for it's relatively excellent ratio of conductivity to density.

Test Plans

We will test to make sure our Engineering Requirements are satisfied.

ER1.1 APRS Transmissions: Minutes between transmissions (min: 10, ideal: 1, max: 0.5)
The Tracksoar APRS code is open source. We will modify the code to set the transmission rate as desired (most likely as a variable/parameter that can be modified) and observe the results.
ER1.2 Video with Data Overlay
The system either passes or fails this requirement. Data from the Raspberry Pi Zero and video from the analog video mux, which provides a signal from one of the analog video cameras, can be provided to the OSD part and the output can be observed to test the system. A test was already performed with an analog video camera, Raspberry Pi Zero, OSD-232, and TV to show the the video with data overlay works.
ER1.3 Commands Successfully Received and Executed: Percentage (min: 50%, ideal: 80%, max: 100%)
Once the communication subsystem is up and running, we can just transmit a large sequence of commands and analyze what is received and decoded by the platform.
ER1.4 Data Telemetry and Command: Frequency Band (min, ideal: 2m band)
Once the communication subsystem is up and running, we can test receiving data on the band from our ground station, and we can test sending commands from our ground station and observing if the platform receives them.
ER1.5 ATV Transmission: Frequency Band (min, ideal: 70cm band)
We can test sending video with the ATV Transmitter and receiving it with the METEOR ground station for the desired band.
ER1.6 Telemetry Transmissions: Minutes between Transmissions (min: 10, ideal: 1, max: 0.5)
Once the communication subsystem is up and running, we can test transmitting data from it to the ground station and observing the interval between data transmissions.
ER1.7 Antenna: Type (min, ideal: omni-directional)
This engineering requirement is a design requirement that does not need to be tested; we just need to buy such an antenna.
ER1.8 Collected Data Storage: Percent (min: 20%, ideal: 80%, max: 100%)
Once the communication subsystem is up and running, we can let it run for a while and then compare the amount of data stored on the MicroSD card with the amount of data (calculated value) that should have been collected in the time interval.
ER2.1 & ER2.2 COMMS-DAQ Subsystem Integration
The system either passes or fails this requirement. During integration and assembly, it will be obvious whether or not the two systems will physically fit in the platform together. The data communication between the two teams (data from DAQCS to COMMS and commands from COMMS to DAQCS) can be tested with a Raspberry Pi Zero (main COMMS board) and MSP430 (main DAQCS board) on a lab bench.
ER2.4 Overall Weight: Pounds (max: 6 lbs)
The final system can be weighed with a scale.
ER2.5 Passive Thermal System: Celsius (min: consumer, ideal: industrial, max: military)
No current known method of testing - altitude chamber not readily available. Components can be tested at temperatures to test for operational ranges however a combined de-pressuring and temperature setting environment is not available. This is made more complicated by the fact that the HAB does not stablize at an altitude, instead is performing over a continuously changing environment - and at different rates for ascent and descent. No current projected combined testing method.
ER2.7 Number of Connection Points: Number (min, ideal: 4, max: 8)
The final platform can be visually observed to determine whether or not this requirement has been met.
ER3.1 Mission Duration: Hours (min: 2, ideal: 3, max: 4)
Calculations can be performed to ensure that there is enough power for the system to operate in the required time frame. The platform will have to be observed (visually and with sensor data) during an actual launch to check the mission duration.
ER3.2 Mission Wear on System: Percent Wear
After each system flight, check over system components to find any of the following: water absorption, physical wear, dis-mounted components, dry thermal paste, torn foil connections, worn wires, loss of conformal coating, or malfunctioning components. Should any of the above result in lose in mission capabilities then the test would be considered a fail.
ER3.3 Elevation above Sea Level: Feet (min: 90,000, ideal: 120,000, max: 140,000)
Simulations can be performed to ensure the system can survive the environmental factors from sea level to the specified elevations. The platform will have to be observed (visually and with sensor data) during an actual launch to check elevation and system survival.
ER3.4 System Failure: Failures Per Mission (ideal: 0, max: 0.0000001)
One or more launches will be performed. The system should not fail. If it does not (desired data is obtained and other requirements are met), then it passes this requirement.
ER3.6 System Recoverability: Recoveries/Mission (min, ideal: 1)
One or more launches will be performed. If the system is found and recovered, then it passes this requirement.
ER3.7 Free Fall Survival Height: Feet (min: 15, ideal: 25)
A structural prototype could be created and dropped from a height that meets the requirements (down a stairwell or off a building). If it survives, the structure passes. A full test would involve dropping the complete system.

Test Plans

Risk Assessment

Risk Management

Risk Management

The risk assessment document has been updated. Owners have been assigned to each risk. The likelihood of not finding an ATV Transmitter or locating the platform have both been reduced since we have purchased and received an ATV Transmitter that works and are adding a redundant GPS module.

Moving forward, the highest risk is not having an altitude chamber to test the HAB in prior to flight. The issue has been discussed in detail and there simply is no solution to the issue other than allocating resources for offsite testing.

The working power document can be found here: Risk Management

Design Review Materials

The following presentation was given on November 3, 2016: Preliminary Detailed Design - Design Review Presentation

Notes from the design review can be found here: Preliminary Detailed Design Review Notes

Plans for next phase

Next Phase Gantt Chart

Gantt

Gantt

The working Gantt Chart can be found here: Microsoft Project

Individual Goals


Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Integrated System Build & Test with Customer Demo | Customer Handoff & Final Project Documentation