Preliminary Detailed Design
Team Vision for Preliminary Detailed Design PhaseGoals for this Phase:
- Develop a structure design
- Develop a software operation/function diagram
- Pick out APRS, 70cm ATV Transmitter, 2m transceiver (or plan to make one), GPS, and video overlay board
- Determine microcontroller configuration
- Determine interfaces between systems
- Finalize BOM for main components
- Purchase parts to begin prototyping and testing
- Define ground control commands
- Develop test plans for engineering requirements
- Enhance cost, weight, and power estimates
- Design the power system
- Develop high level electrical schematics/diagrams, specifying interfaces, power requirements, and data storage details
- Plan out component placement in/on the structure
- Perform more thermal analyses
- Performed bringup of OSD-232 module
- Developed an OSD API
- Performed bringup of VideoLynx ATV Transmitter
- Development of power and battery architecture
- Evaluated and selected between 3 different 2m packet transmission architectures
- Selected major components (2m transceiver parts, video mux, APRS, antenna equipment, and more)
- Purchased ATV Transmitter, 2m transceiver parts, and APRS
- Further refinement of high-level system architecture, using Raspberry Pi as main COMMs host
- Developed physical system design
- Developed initial structure prototypes
- Delivered prototypes for associated testing - control
- Identified external geometry scheme for energy dissipation
- Developed power management plan for communication subsystem
- Updated weight and budget analyses
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
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.
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.
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.
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.
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.
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.
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 OverlayUsing 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.
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 PlanIn 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.
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).
- The UART interface can be used for the OSD with a level converter (for RS-232).
- The MicroUSB connector of the Pi Zero can be used for our transceiver plan.
- SPI will be used to interface with the HABIP-DAQCS team.
- GPIO will be used to control the select of the analog video multiplexer
- I2C: DAC to control ATV transmitter potentiometer for RF output control, temperature sensor(s), redundant GPS
- I2C or SPI for APRS
- MicroSD support built into the Raspberry Pi Zero for storing data relevant to the communication subsystem
The Raspberry Pi Zero can cover all of the above interfaces.
Power AnalysisWe have created a more detailed power analysis for the communication subsystem.
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.
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.
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 AnalysisWe 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
We have been collecting the physical characteristics of our selected parts. Operating temperature ranges, weight, and dimensions are important.
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 CommandsThis 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
- Change analog camera source (1 of 4 cameras)
- Change APRS transmission interval
- Change what data is shown over the analog video by the OSD
- Change data transmission interval
- Change HD cameras between video and picture modes
- Command to turn the reaction wheel on/off (enable it) (it will also most likely be enabled/disabled based on relative altitude)
- Command to tell the reaction wheel to turn by a certain amount of degrees
- Modify the ATV Transmitter output power
Preliminary List of Commands to the DAQCS Side
Not all of these commands necessarily have ground commands.
Commands to request data:
- Request temperature from 1 of 3 sensors from 1 of the 4 Raspberry Pi Zero boards
- Request pressure/altitude from 1 of the 4 Raspberry Pi Zero boards
- Request IMU data from the MSP430
- Request temperature data from the MSP430
- Start all sensor logging
- Time sync for logging
- Tell Raspberry Pi Zero boards to toggle between video and picture modes
- Process status request
- Command heading for reaction wheel if add compass; if not, give it amount of degrees to turn
- Command to turn reaction wheel on/off
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:
- Redundant GPS module
- Temperature sensor (to keep track of the temperature of the custom PCB board)
- RS-232 level translator for the OSD module
- Analog video mux
- Audio breakout & circuitry (like attenuation?) for transceiver
- Power management for the communication subsystem (and DAQCS analog video cameras)
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 DesignWe will need to develop software coding standards in the next phase.
The diagram below shows the high level software flow for the Raspberry Pi.
Power Management Diagram
RF Connections Diagram
The connections from the ATV Transmitter and transceiver to the antenna on the platform are shown below.
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.
The working document can be found here: Bill of Materials Spreadsheet
Part SelectionThis section goes into our decisions for the selection of major parts.
- 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.
- 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.
- We went with the MX72H Duplexer since it has been used in past METEOR projects and is in our budget.
- 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.
- 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.
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.
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
- Decide on detailed component placement
- Draw a mechanical/CAD model of the design
- Perform thermal analysis and plan out thermal routing/control
- Test heatsinking for ATV and reaction wheel components
- Purchase the rest of the major COMMS components
- Purchase evaluation board for analog video multiplexer
- Test ATV with multiple analog cameras and the video multiplexer
- Scope out and test METEOR equipment for both 2m and 70cm
- Prototype and test 2m transceiver subsystem
- Combine 2m and 70cm systems with duplexer, and test
- Test OSD with Raspberry Pi API
- Test APRS
- Write APRS API
- Write GPS API [12/5-12/8]
- Write temperature sensor API
- Develop custom PCB board schematic
- Develop more detailed schematic for COMMS subsystem
- Develop communication protocol between COMMS and DAQCS team
- Develop communication protocol between COMMS and ground
- Develop software/program flow diagrams
- Test communication systems at a distance from METEOR lab
- Enhance test plans
- Create pre-flight test plan
- Finalize BOM
Next Phase Gantt Chart
The working Gantt Chart can be found here: Microsoft Project
- Ian's Phase 4 Individual Plan
- Matt's Phase 4 Individual Plan
- Connor's Phase 4 Individual Plan
- Adam's Phase 4 Individual Plan