P17104: HABIP-COMMS
/public/

Detailed Design

Table of Contents

Team Vision for Detailed Design Phase

Goals for this Phase:

Accomplishments:

Progress Report

The 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.
Tasks for Review

Tasks for Review

Completed Tasks

Completed Tasks

Remaining Tasks

Remaining Tasks

What decisions have been made so far?

What questions does the team have for the customer and/or guide in order to continue moving forward? N/A

Drawings and Schematics

Drawings and Schematics

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 Prototyping

At 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:

2m Transceiver High Level Schematic

2m Transceiver High Level Schematic

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!

AX.25 Listening!

AX.25 Listening!

Transceiver Prototyping

Transceiver Prototyping

Documents:

APRS Prototyping

We 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.
APRS Tracking

APRS Tracking

Documents:

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.

NTSC Camera

NTSC Camera

Custom PCB Contents

We will have 1 custom PCB for the communication subsystem.

It will have the following components:

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.

RF Shielding

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:

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

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.

Metal Framework Design Weights

Metal Framework Design Weights

Design, Drawings, Schematics, Flow Charts

Platform Design

Design 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.
Platform Final Concept / Design

Platform Final Concept / Design

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.

COMMS Compartment

COMMS Compartment Design

COMMS Compartment Design

Below is a summary of component allocation and design reasoning.

COMMS Compartment Design

COMMS Compartment Design

COMMS Compartment Design

COMMS Compartment Design

DAQCS Compartment

DAQCS Compartment Design

DAQCS Compartment Design

Below is a summary of component allocation and design reasoning.

COMMS Compartment Design

COMMS Compartment Design

COMMS Compartment Design

COMMS Compartment Design

Assembly Plans

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.

Platform Assembly Plans

Platform Assembly Plans

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 0026615020 0009503021 0008560106 2 22awg 1x 7.4V Battery
Molex 0026615020 0009503021 0008560106 2 20awg 1x 11.1V Battery
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
It will also have the Sparkfun WRL-00593 SMA connector for attaching the GPS antenna and 4x Sparkfun PRT-12639 3.5mm TRSS audio jacks for our transceiver set-up.

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 Connections

Here is a block diagram of the RF connections:
RF Connections Block Diagram

RF Connections Block Diagram

Here is an image of the connections with the actual parts:

RF Connections Image

RF Connections Image

See the BOM for the cables and connectors.

Schematics

Main COMMS Schematic

Here is a block diagram of the COMMS subsystem:

Comms Block Diagram

Comms Block Diagram

Custom PCB Schematic

Here is a block diagram of the custom PCB:

Custom PCB Block Diagram

Custom PCB Block Diagram

Here is a block diagram of the power management for the custom PCB:

Custom PCB Power Management Block Diagram

Custom PCB Power Management Block Diagram

Here are the actual power management schematic pages for the custom PCB:

Custom PCB Schematic Page 1

Custom PCB Schematic Page 1

Custom PCB Schematic Page 2

Custom PCB Schematic Page 2

Custom PCB Schematic Page 3

Custom PCB Schematic Page 3

Here are the rest of the schematic pages for the custom PCB:

Custom PCB Schematic Page 4

Custom PCB Schematic Page 4

Custom PCB Schematic Page 5

Custom PCB Schematic Page 5

Custom PCB Schematic Page 6

Custom PCB Schematic Page 6

Custom PCB Schematic Page 7

Custom PCB Schematic Page 7

Custom PCB Schematic Page 8

Custom PCB Schematic Page 8

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 Design

An 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).

Detailed Software Flow Chart

Detailed Software Flow Chart

Protocol Buffers

The 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.
Comms Protocol Buffer Format

Comms Protocol Buffer Format

Our User's Manual for our Protocol Buffer's can be found here.

I2C Addresses

Multiple 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
APRS Configurable 011 1101
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.

Budget

All items purchased or to be purchased:
Budget

Budget

Here is a PDF of the above: Purchased Items

Here is a Pi Chart of our budget:

Budget Pi Chart

Budget Pi Chart

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:

We could use $400-500 additional funding for the following:

BOM

BOM of minimum items required to build the COMMS subsystem of the platform:
Minimum BOM

Minimum BOM

Here is a PDF of the above: Minimum BOM

Additional Connectors

Connector Housings and Crimps (connectors on custom PCB included in custom PCB BOM):
Connectors BOM

Connectors BOM

Current Mechanical Component BOM:

Mechanical BOM

Mechanical BOM

This does not include foil, machining costs, mounting parts, and more.

The working document for the mechanical BOM can be found here: Mechanical BOM Spreadsheet

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 Plan Documents

Design Review Materials

The 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:

Our current plan for the next phase can be found here: MSD II Plans

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