Team Vision for Detailed Design PhaseGoals for this Phase:
- Determine component placement in structure
- Develop structural model
- Perform thermal analysis/planning
- Finalize BOM
- Finalize budget
- Prototype ATV transmitter subsystem (not required; bonus)
- Develop and test 2m transceiver subsystem (testing not required; bonus)
- Purchase all major components for the platform
- Develop software plan
- Develop communication protocol between COMMS and DAQCS
- Develop communication protocol between COMMS and ground
- Test APRS (not required; bonus)
- Create custom PCB schematic
- Create electrical wiring plan (connectors, number of wires, gauges)
- Create mechanical wiring plan (how connections will be routed through structure)
- Look into RF shielding
- Enhance overall COMMS schematics with pin numbers and more details
- Develop test plans
- Determine component placement in the structure
- Develop structural model
- Develop assembly method with parts
- Thermal Plans
- BOM almost finalized (missing wires, custom PCB assembly, foil, and some mounting parts)
- Budget updated based on BOM
- Purchased all major components for COMMS subsystem
- ATV transmitter subsystem tested with single camera, OSD module, and ATV transmitter
- 2m transceiver subsystem tested with Pi Zero, USB audio adapter, and Baofeng Radio (received and decoded APRS packets; transmitted data)
- Got APRS running and transmitting GPS position information
- Created custom PCB schematic
- Created electrical wiring plan
- Created mechanical wiring plan
- Created test plans
- Looked into RF shielding
- Enhanced schematics
- Developed test plans
Progress ReportThe tables below show the progress of the team prior to Thanksgiving break on November 22nd. By the end of the semester and upon the completion of MSD I, it is hoped to have the “percent complete” column to be 100% for all task items.
What decisions have been made so far?
- The majority of components have been decided upon (only structure and small PCB components remain)
- Our hardware designs are done at a high level. We still need some more details, most specifically for the custom PCB.
What questions does the team have for the customer and/or guide in order to continue moving forward? N/A
What % of critical parts or material ordered? 95% of critical parts have been ordered for early stage development
What % of critical parts actually received or fabricated? ~90% have been received
What % completed of the wiring/harnessing design? ~20% has been completed. On the DAQCS side, there has been more work in regards to how all of the sensors will be physically connected and mounted. On the COMMS side, connectors need to be determined.
Prototyping, Engineering Analysis, Simulations
Transceiver PrototypingAt the beginning of this design phase, the plan was to use MiniModem, which modules (and demodulates) data using AFSK (Audio Frequency Shift Keying). However, after speaking with other HAM operators, we came to the conclusion that we should be using an AX.25 packet structure to send our data. AX.25 still modulates data using AFSK, however, there is a more structured packet header that is standard in the HAM community. Therefore, these packets will be able to be read and stored by any HAM with the appropriate TNC controller.
The setup is similar to before, where a Raspberry Pi is used to generate/receive these AX.25 packets. These AX.25 packets are modulated/demodulated using AFSK, and sent to the Baofeng 2m transceiver using a USB sound card attached to the Raspberry Pi. See the high level diagram below:
Getting this setup required a fair amount of troubleshooting and debugging. Ultimately, numerous AX.25 packet packages were installed to the Linux environment. Next, SoundModem was configured for use to generate AX.25 packets, over the USB Sound Card, at the specified baud rate (1200 bps). Finally, in order to generate AX.25 packets, the "beacon" function was used, and in order to listen for AX.25 packets, the "axlisten" command was used. This assumes an active, running soundmodem process, which can be started using Screen or TMUX.
A more detailed instructional on how to setup this AX.25 packet transceiver, from both a software and hardware perspective, is coming.
Below is a screenshot of the AX.25 listen "axlisten" command running, and receiving AX.25 packets. One of the packets received is from the Tracksoar APRS we purchased!
APRS PrototypingWe received the Tracksoar APRS system recently, and immediately began getting it up and running. In order to get it working, the firmware had to be programmed onto the ATMEGA328p chip. In order to do this, an FTDI programmer was required. The firmware is Open Source and available on the manufacturer's website. After modifying the call sign to ours within the firmware, and programming the board, the APRS was up and running. See the image above, which shows an APRS location packet being received on our 2m transceiver. The only issue we had was getting a GPS lock on the APRS board. This was most likely caused by the buildings on campus obstructing satellite reception.
Color NTSC Camera
We received one of the possible color NTSC cameras (shown in the image below). The color and quality of the camera is very good, however it does not seem that the camera can focus at far distances. We will have to pick a new camera.
Custom PCB Contents
We will have 1 custom PCB for the communication subsystem.
It will have the following components:
- Redundant GPS module
- Antenna for GPS
- 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 for transceiver
- Power management for the communication subsystem (and DAQCS analog video cameras)
- Pressure sensor (to keep track of elevation on COMMS side for controlling ATV Transmitter output power)
- Digital potentiometer to control ATV Transmitter output power
- Connector to connect custom PCB to host Pi Zero
- Connectors to connect COMMS subsystem components
- Connector to connect to DAQCS host MSP430
The custom PCB will be 4 or 6 layers. Special consideration must be taken into account for the RF for the GPS module and audio for the transceiver set-up. A shielding box will probably be used for the audio section of the PCB.
During prototyping, we found that the Baofeng radio caused the Pi Zero to have issues; transmission with soundmodem did not always work. However, when the radio was connected to an antenna further away from the Pi Zero, there were no issues. Therefore, it was an RF interference issue.
After talking with professors, we believe that there should not be an issue with the actual platform since the antenna is outside of the platform (and it will be omni-directional, pointing down) with a layer of foil (for thermal purposes) between it and the inside contents of the platform.
Research into RF shielding has been performed. If there is still an issue once the platform is created, it will be addressed then. Solutions:
- RF shielding fabric or mesh
- Tin foil or copper foil for shielding
- Put shielding boxes over boards
- Torroids at ends of wires
Thermal Design Schematic
The design of the structural's thermal frame was developed using an aluminum framework, conducting from the internals of the HAB radially outward, and effectively convecting and radiating to the surroundings during flight. Circuit Design assumed symmetry about the central axis of rotation, which is believed to be valid as the thickness of the frame is along terms of multiples of .0063 inches - the average thickness of a sheet of aluminum foil. At this thickness, spacial properties deviate less as a function of position, being dominated by the temporal dimension. With this being true the frame was discretized into finite nodes depending generally on radial distance. Full disks were separated into two radial nodes while the metal covering on the outside was kept at one node, however when lined in series mimic-ed a multiple node discretization.
Structure Thermal Circuit - Note that the resistances and capacitances are generalized - as the specific values are geometry dependent
Design of the frame thicknesses were developed using the circuit model by placing current inputs (heat transfer inputs) at various nodes where components were placed, namely T4, T5, T10, T11, T15, and T16.
With generalized angular dimensions, extensive simulation could be not performed however the following extreme risks were found: ATV low temperature failure and motor high temperature failure. With the ATV placed near an external wall the conduction is too rapid, and so additional resistance design is required to maintain heat to the batteries adjacent to the transmitter. A partial covering surface covering will remedy this fact. A considerable risk component is the motor because of the relatively high heat generated from it. It does however have a significant flat surface area to aid in conduction. Being placed at the center, the motor will experience the highest temperatures, and that will in turn be reflected upon the RasPi units on the same level. To remedy this the majority of metal framework will be incorporated on this layer. The bottom is a summary of the design weights of the metal framework.
Design, Drawings, Schematics, Flow Charts
Platform DesignDesign of the HAB platform is complete. Originally the platform was design for a 12 inch diameter at roughly 5 inches tall. This however was not achievable due to a handful of spatial constraints including the IMU and Reaction wheel placements. The final specs for the structure (Insulation base - metallic framework is addressed later on page) are as follows: 10 inches tall at a diameter of 14 inches. The insulation base weighs in at exactly .8 lbs.
The structure is sub-divided into two distinct sections by three layers, labeled the top, middle, and bottom layers. The top compartment between the top and middle layer is reserved primarily for DAQCS side components while the the compartment from the middle to the bottom layer is reserved for COMMS components. While this is true, there is inter-subsystem interaction and as such the compartments are not completely modular. Female-Female connections will integrate the two layers at the base of the middle layer, integrating all components of the HAB platform.
Below is a summary of component allocation and design reasoning.
Below is a summary of component allocation and design reasoning.
The HAB platform was designed to be as modular as possible. This fact benefits assembly in terms of ease of application, assembly, etc... however had the converse effect of increased weight. Being such, assembly components (Screws, bolts, etc...) are required to be kept to a minimum. As such the following has been decided.
Mechanical Wiring Plans
Since the component design was developed in compartments there is minimal intra-layer wiring. For the handful of COMMS and DAQCS components that require to wire down to the bottom layer it has been decided that a female-female connection will be made at a common junction at the middle layer.
On the COMMS side, their custom pcb was placed directly above both the ATV and Baofang, and right next to the OSD, leaving minimal wiring. Among all COMMS components, the largest wiring diameter comes from the Duplexer. In order to prevent possible issues, the Duplexer has been positioned so that the wires can conform to the inside wall of the platform, wrapping around to the ATV and Baofang, which are along side the wall as well. Should there be any additional wiring issues, "Mountable Cable Ties" (Purchased from McMaster Carr) will be used.
Electrical Wiring Plans
Connectors on Custom PCB:
|Manufacturer||Board Connector Part Num||Housing Part Num||Crimp Part Num||Number of Pins||Wire Gauge||Quantity||Destination|
|Molex||0022122024||0010112023||0008550124||2||30awg||3x||OSD Power, OSD Video, OSD Data|
|Molex||0026615020||0009503021||0008560106||2||22awg||2x||2m transceiver and 70cm ATV transmitter power|
|Molex||0022122034||0010112033||0008550124||3||30awg||6x||APRS, 4x Analog Cameras, ATV potentiometer|
|Molex||0022122054||10-11-2053||0008550124||5||30awg||1x||SPI to DAQCS|
|Sullins Connector Solutions||SFH11-PBPC-D20-ST-BK||PRPC020DAAN-RC||N/A||40||N/A||1x||For mounting Pi Zero|
The Pi Zero will be mounted on top of the custom PCB. It will have the male 2x20 2.54mm header soldered to the bottom of it so that it still faces up. The custom PCB has a female 2x20 2.54mm header, which the Pi Zero will be inserted into. There will be 4 stand-offs between the custom PCB and the Pi Zero (located at the 4 corners of the Pi Zero).
Here are crimping tools for:
We have a professor with better crimping tools that he said should work for our connectors.
RF ConnectionsHere is a block diagram of the RF connections:
Here is an image of the connections with the actual parts:
See the BOM for the cables and connectors.
Main COMMS Schematic
Here is a block diagram of the COMMS subsystem:
Custom PCB Schematic
Here is a block diagram of the custom PCB:
Here is a block diagram of the power management for the custom PCB:
Here are the actual power management schematic pages for the custom PCB:
Here are the rest of the schematic pages for the custom PCB:
A PDF of the custom PCB schematic can be found here. We are using EAGLE for the schematic and layout of our custom PCB.
Software DesignAn overview of the software components going into this design.
Detailed Software Flow Chart
The following image outlines the detailed software flow that will be carried out by the program(s) running on the main controller (Raspberry Pi).
Protocol BuffersThe protocol buffers will be used as the method to format any data to be sent/received both for serial communications and wireless. The provide a simple, yet very powerful approach for organizing the data in a structure that is platform and semi-language agnostic. There are few open source protocol buffer implementations and the one chosen for this is the implementation developed and maintained primarily by Google found here.
Our User's Manual for our Protocol Buffer's can be found here.
I2C AddressesMultiple components will share a single I2C bus. Their individual addresses (7-bit values) are recorded below:
|Device||Possible Part Address(es)||Final I2C Address|
|Temperature Sensor||100 1xxx (x = A2 A1 A0)||100 1000|
|Pressure Sensor||111 011x (x = CSB_BAR)||111 0111|
|GPS||100 0010 by default||100 0010|
|Digital Potentiometer||010 111x (x = A0)||010 1110|
|APRS BME280 Press/Temp/Hum||111 011x (x = SDO)||111 0110|
The GPS I2C address can be modified by configuring registers in the module, but we will use the default address.
As is, the APRS has an on-board BME280 pressure/temperature/humidity sensor. However, we have not got that sensor portion working yet. Instead, the APRS can be set up as an I2C slave. It would lose the ability to communicate with the BME280 sensor, but it could use whatever data it was supplied over I2C. Most likely, we will use the I2C connection on the custom PCB for the APRS to give it some data to send down with the GPS information. The APRS I2C slave address can be set to anything.
Bill of Material (BOM)
The working document for our BOM can be found here: Bill of Materials Spreadsheet
The custom PCB BOM (exported from EAGLE) can be found here: Custom PCB BOM
It can be imported into Digi-Key (all parts but 2, which are from SparkFun, are from Digi-Key); the quantity and vendor part number columns are used by the Digi-Key tool.
BudgetAll items purchased or to be purchased:
Here is a PDF of the above: Purchased Items
Here is a Pi Chart of our budget:
We only have $138.61 remaining in the budget. We have not yet accounted for electrical wires, foil, machining costs, mounting hardware, and more. The budget also only includes the cheapest 4 layer board manufacturing for our custom PCB. With pcbway, the price would go from $70 to $220 to move to a 6 layer board. At other companies (like Advanced Circuits, OSH Park, and more), the price would be even higher. Pcbway also provides 10 copies of the board, while we only have included the price of custom PCB components to assemble a single board. Ideally, we would have 3-4x the number of components needed to populate a single board, which would be an additional $101.06 per board.
We will also be able to save $12.91 (per board worth of components we buy) by getting free samples of the following TI parts:
- CSD17579Q3A (save $0.67)
- TPS562209DDCT (save $1.33)
- LP2985-33DBVR (save $0.58)
- LMZ34002RKGR (save $10.33)
We could use $400-500 additional funding for the following:
- Have a 6 layer board
- Get multiple copies of the components needed for the custom PCB
- Have more money toward the structure
BOMBOM of minimum items required to build the COMMS subsystem of the platform:
Here is a PDF of the above: Minimum BOM
Additional ConnectorsConnector Housings and Crimps (connectors on custom PCB included in custom PCB BOM):
Current Mechanical Component BOM:
The working document for the mechanical BOM can be found here: Mechanical BOM Spreadsheet
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 Plan Documents
- ATV System Test Plan
- 2m Data Transceiver Test Plan
- APRS System Test Plan
- Custom PCB Test Plan
- Platform Coupling Test Plan
Design Review MaterialsThe following presentation was given on December 8, 2016: Detailed Design Review Presentation
Notes from the design review can be found here: Detailed Design Review Notes
Plans for next phase
The main plans for the next phase are as follows:
- Review & finalize custom PCB schematic
- Develop custom PCB layout
- Further testing of transceiver and ATV transmitter subsystems
- Develop Pi Zero software
- Develop mechanical drawings
- Making the structure
- Create more technical documentation
Our current plan for the next phase can be found here: MSD II Plans
- Ian's Phase 5 Individual Plan
- Matt's Phase 5 Individual Plan
- Connor's Phase 5 Individual Plan
- Adam's Phase 5 Individual Plan