NASA Suborbital Flight Communication and Fire Box

=Problem Definition= This project continues the work completed by the previous University of Idaho capstone teams who have partnered with NASA Ames Research Center on developing a communications system for a Tube Deployed Re-entry vehicle (TDRV). Previous teams have done a variety of groundwork such as building a guided parafoil system that can move a returning payload in order to reach a pre-determined GPS location during its descent. Other work, accomplished by the most recent team, includes creating a carrier module capable of controlling and housing the Iridium 9523 modem in order to help integrate into future returning cube satellites. Lastly, a previous team developed the initial codebase for communicating over the Iridium satellite network utilizing the Iridium 9523 via SBD (short burst data) messages. They also attempted to implement dial-up capabilities but were unsuccessful. Our team is building off of these previous groups and creating a fully functional communication system through an Iridium 9523 connected to a carrier module that is powered by Canon BP-955 batteries in a fireproof containment unit. The end product will be a cheap, reliable, and physically safe system capable of real-time data communication with a returning satellite. The project can be broken down into 3 main components:  The software necessary to provide communication through the Iridium network. The carrier module re-design necessary to host the Iridium-9523 module in a smaller form factor. The battery box to store the Lithium-ion batteries necessary to power the system in a safe way. 

=Deliverables=   Software:   An Arduino compatible software library written in C++ for a microcontroller capable of using an onboard Iridium-9523 modem to allow for SBD (short burst data) and dial-up communication via the Iridium satellite network.  This software must properly power the carrier board the Iridium modem on startup.</li> It must also parse data from TechEdSat (TES) and forward the message to the Iridium-9523.</li> Incoming data that is received by the Iridium-9523 modem must be parsed by the microcontroller and forwarded to TES.</li> The microprocessor must keep track of which state the Iridium-9523 modem is in and be capable of switching based on the input from TES.</li> Encryption and decryption capabilities should be added to increase the security during data communication.</li> </ul> A server capable of receiving and parsing transmitted information from the Iridium modem and storing the messages locally.</li> </ul>  Carrier Module: </li>  Fully functional Iridium Carrier Module confined to the PC-104 form factor.   A re-design power circuitry for power efficiency and power isolation.   An upgraded microcontroller to support custom software's needs </li>  Schematics and documentation of re-design carrier module with reduce noise and thorough shielding ready for manufacturing. </li> </ul> </li>  Carrier module component test board </li>   Report on the effect of vacuum and orbit temperatures on the functionality of various types of capacitors and resistors, and the performance differences between typical and high-performance resistors. </li> </ul> </ul> <li> Battery Box: </li> <ul> <li>A lightweight “firebox” capable of containing a fire as a result of thermal runaway caused by batteries used to power the reentry module.</li> </ul> </ul>

=Specifications= The requirements as outlined by our client are shown below: <ul> </ul>

=Project Learning=

Software:
The initial hurdle that the CS subteam had to research and overcome was getting the carrier module to power on correctly and provide proper communication between all possible ports. This includes the microcontroller, Iridium-9523 modem, and TES ports. To learn how the board was built and how to use it, we had to reach out to the previous design team creator, Avery Brock, for plenty of questions and advice on how to fix the board and ultimately get it working. This also required the aid of our Electrical engineers to read over the Eagle schematics and determine which jumpers needed to be moved in order to fix problems with power so we could move on with our project and actually develop code for a board that works. The helpful files we used as research for this carrier board can be found here: Carrier Board Files In order to develop the software library, we decided to first research what previous University of Idaho capstone CS subteams completed to give us a reference for how to move forward. We quickly learned that although some of these teams accomplished SBD functionality, they did so on different hardware platforms under different restraints. For instance, they used NAL specific hardware (the black box) to communicate with the Iridium modem while we are developing for a microprocessor (SAMD21) on a custom carrier board designed by a previous design team. This indicated to us that we have to go about our software design differently, but can still use specific commands called by their code within our own since we learned that the Iridium modem responds to general AT (ATtention) commands. Also, we were given the goal of implementing dial-up communication which no previous teams were able to successfully achieve so this had to be researched separately. Most of this helpful information was found in Iridium AT reference guides and general Iridium manuals. The link to previous design team information can be found here: Previous Team Information The link to Iridium specific information and AT commands can be found here: Iridium Information Late Research: We discovered in February 2020 that in order to utilize the dial-up connection we establish, the board must have a TCP/IP stack in order to send and receive messages. Upon initially looking into a solution, we found a lightweight implementation for embedded systems called lwIP that seems promising at the expense of system resources and programming effort. An alternate option to implementing our own stack would be to bypass it altogether by switching the data plan from a dial-up connection to a RUDICS (Router-based unrestricted digital internetworking connectivity solution) connection. According to the NAL website, RUDICS is an enhanced gateway that connects a call to a pre-defined IP address that allows for an end-to-end IP connection between the host application and ISU. The three main benefits of RUDICS over dial-up would be: <li>The elimination of analog modem training time.</li> <li>An increased call connection quality.</li> <li> Protocol independence: This eliminates the need for a TCP/IP stack implementation! </li> </ol> This third benefit is the main reason switching to RUDICS over dial-up is the best option for NASA ARC (Ames Research Center) moving forward. This reduces the stress on the board by eliminating the need for an internet stack and provides all the other benefits listed and more. As of the design EXPO, NASA has not been able to switch their data plan to RUDICS due to an expensive upfront fee required, but we have advised them of our research and recommendation to switch in this area and they are in the process of switching for either future design teams or their own internal software development on this project.

Carrier Module:
One of our main goals in this project was to re-design the carrier module built by the previous team. Thus, the first challenge was to test and validate the design of the previous carrier module. Thankfully, the previous teams left some great resources and documentation that made the test and validation possible. Our team decided to build on the previous team design and upgrade components as necessary to meet our new design requirements.

A component test board was created to test passive components such as capacitors and resistors. Our initial design was a series of voltage divider circuits for both resistors and capacitors. But, it was difficult to test and voltage regulators do not work for polarized capacitors. A better solution was to use an analog multiplexer to connect each component to an external LCR meter. Although the new design has some limitations (i.e. the components should be rated for &plusmn;40C), it allows testing all components without having to re-pressurize between tests. Using this design for component test board meets our design requirement on reporting on the functionality capacitors and resistors in vacuum and orbit temperatures.

The new design requirements require a new power circuitry to accommodate data streaming and bursting over the IRIDIUM network while providing power efficiency. Thus, we decided to replace the linear regulator with a new boost converter circuit for the data bursting. Because of one of space constraint, the boost circuit needed to use smaller components while providing the power boost and efficiency required. Several trade-offs were made for components such as capacitors, inductors, and ICs (Integrated circuits). We found ourselves making similar trade-offs throughout the design process.

The need to upgrade the SAMD21 to a SAMD51 was to meet the space constraints while providing the capability to carrier module to host complex custom software. The SAMD21 has fewer I/O than our requirements. To solve the issue of the lack of I/Os, the previous teams used an IC expander. But, by switching to the SAMD51 which has more I/O, we were able to remove the expander entirely. With the new space gain, we decided, in conjunction with our client, to use an external flash memory to allow the hosting software with a large binary size.

During our design process, we switch from the Eagle EDA (which the previous team was using) to Kicad. Luckily for us, Kicad has a built-in feature for automatically importing a project from Eagle. However, we run into some issues with components' libraries and their placement into the schematic. Manually, editing was sometimes necessary to fix these issues. The main reason to switch to Kicad was to facilitate the collaboration of the team members.

The principal tool we used to collaborate was Git for version control and Github for a central repository. Unfortunately, we learned that version control does not play well with EDA schematic file formats! Not only, merge changes from another team member in the same branch was nearly impossible, but also sometimes made the branch unusable. Our solution was to follow a strict guideline and use multi-sheet schematics. Our guideline requires that at any time, only a single team member should be working on a specific version control branch. Additionally, each team member was allowed to work on his assigned hierarchical schematic file. Finally, when a team member needed to make changes to another schematic, it should do so after having informed the other team members.

Battery Containment Unit:
As outlined in the design specifications, the battery insulation box must withstand the mechanical and thermal shock of an explosion resulting from thermal runaway of Canon BP-955 batteries. Since thermal runaway produces hydrogen gas at a temperature exceeding 500oC and flames we must design a ventilation system that will vent the hot gasses while containing the flames. A potential material to fulfill these requirements are open-cell metal foams. Metal foams are metals with built-in pores, where 25% of the volume is occupied by air. Several of the chemical and physical properties are left unaffected. Namely Thermal/electrical conductivity, melting point, corrosion resistance, and reactivity. However, The addition of porosity creates a larger surface area. The major effect we would see is the increase in heat absorbed during contact. The large surface area makes metal sponges great heat sinks where energy is transferred energy away from the batteries in the event of thermal runaway. The absorption of energy is effective enough to make metal foams an effective material to quench flames. Since the box is designed to contain four batteries and prevent thermal runaway we must thermally isolate each battery. To do this and maintain within the weight and size constraints an aerogel or aerogel like material is needed. Aerogels are ultralight porous ceramic materials that are typically 98% air. The high distribution of the nano-sized pores inside the Aerogel creates excellent thermal and electrical insulation. However, the silica skeleton is incredibly brittle and the quantity of the pores limit airflow. Aerogel insulation blankets are produced by submerging a polymer, typically polyethylene terephthalate (PET), felt with silica gel before creating the aerogel. The polymer-stabilized aerogel insulation blankets are flexible with an operating temperature of 350oC and a density of 0.15g/cm3. High-temperature insulation blankets are produced by stabilizing the aerogel with fiberglass instead of PET. Pyrogel XT-e, is an example of a high-temperature aerogel insulation blanket. It has a density of 0.2g/cm3 and an operating temperature of 650oC. Initial learning consisted of reaching out to Mechanical and Material Science Engineering professors, listing possible materials, conducting a literature review, then narrowing down the selection so a design can be constructed. For farther information please refer to the materials reports.

=Final Design=

Software:
Originally, we set out to implement both SBD and dial-up data transmission capabilities with the option to automatically switch modes throughout its process depending on the input the board receives. To utilize the dial-up capabilities, we would have to implement a lightweight microprocessor stack such as lwIP. The representation of this implementation can be seen in the diagrams below. Original UML Class Diagram: Original UML Activity Diagram: Upon further research mentioned earlier, switching from a dial-up data plan to a RUDICS data plan is a superior option to implementing the lightweight internet stack. This is mainly due to hardware independence indicating that we don't need the internet stack in our final software design. Although NASA was not able to switch the data plan to RUDICS before the end of our last semester, we still implemented RUDICS in our software design so that NASA or a future design team can make a smooth transition from our code to a library that utilizes RUDICS. Our final design can be seen in the diagrams below. Final UML Class Diagram: Final UML Activity Diagram: The program will wait until data is provided from TES. It will parse the incoming data and determine whether it should move from an IDLE state to an SBD state or RUDICS state. A message prefixed with "tx:" followed by any data will signal that the data should be transmitted via SBD. On the other hand, a message prefixed with "dial" will instead establish a dial-up connection. Because we can not use the data connection that we establish, the call is dropped after about 30 seconds and returns the system to an IDLE state that waits for incoming TES messages. However, if it receives a request to send an SBD message, it will perform a series of steps to properly format and send the message. This process first consists of switching the system mode from IDLE to WRITING. It will then call the AT+SBDWB command with the size of the message included and wait for the Iridium to respond with the READY signal. Once it receives this signal, the microprocessor will convert the message to a byte array, calculate the checksum, and then send the message with the checksum attached to the end by initiating an SBD session. If encryption is enabled, the message will be encrypted during this step to provide security throughout the transmission. If encryption is not enabled, the message will be sent as plaintext in byte format. The server we programmed provides basic functionality to receive and store messages. At the moment, it is purely built to receive SBD transmissions due to the fact that RUDICS is not available or implemented yet. However, in regards to these SBD transmissions, the message is initially sent to a Gmail account associated with NASA ARC as an attachment, but a python based script utilizing the Gmail python API will download it and store them locally to the server. This API has the ability to push notifications but it requires Google Cloud integration. In regards to the onboard cryptosystem, we decided to implement AES-128 bit encryption and decryption in CBC mode due to its high reliability for security as an industry-recognized standard and relatively small key and block sizes to reduce the computation impact on the microprocessor. It is an all-around safe and reliable option to provide security in regards to data transfer. We adapted our own implementation from an online one that was originally built in C and formatted it to fit within and work as a C++ class to match our modular design with the rest of our code. The original code did not provide any padding options, so we had to invent our own. AES-128 requires blocks of 16 Byte messages (128 bits) in order to encrypt and decrypt properly so we have to pad to an interval of 16 Bytes to meet this requirement. We ended up developing a padding method that will append the '^' hex Byte until the last necessary padding Byte which is padded with the hex number indicating the total number of padded Bytes that were added to the message string. This method of padding allows for easy removal of the padding when decryption is necessary. The cryptosystem is lightweight and perfect for the microprocessor but needs further testing and modification before it is used by NASA in flight. The shared symmetric key and initialization vector should always be changed on the microprocessor and the server before each official use to ensure that no one can continue to use a key if it is compromised during any flight. The code for our communication software library can be found on the GitHub page here: Software GitHub Page

Carrier Board:
<ul> <li>General Details: <ul> <li>Component Testboard: <ul> <li>The design is finalized, ordered, and assembled. <li>It has been shipped for testing and we are waiting to see how the components performed under near space conditions to ensure a final re-design uses components compatible with these conditions. </ul> <li>The new flight ready carrier module with be a 4-layer board (2 signal planes, power, and GND). <li>Iridium modem will need completely uninterrupted ground plane beneath it. </ul> <li>The re-designed carrier board will follow the block diagram seen below:

<li>The schematic for the new boost converter can be seen below: <li>The re-design will conform to the 104 form factor and appear like the diagram below: <li>The test board design and final build can be seen in the images below: </ul>

Battery Containment Unit:
The Battery box design must conform to a PCB-104 form factor, 3.4in x 3.15in. Additionally, the box must weight less than 500g, ideally 300g. Due to the tight size constraints, the batteries must be packed in the following configuration:

The box will be made out of 3/16in thick 1100 1H4 aluminum with an integrated ventilation system on the top surface. Aluminum is used as the basis for the box due to its stable phase at cryogenic and pyrogenic temperatures. The density and weldability of aluminum will allow us to fabricate a sturdy lightweight box. The vent will be made by welding open-celled aluminum foam to the center of the top surface of the box. The vent will have an internal lining of pyrogel XT-e, or woven silica fabric. A silica aerogel blanket was originally intended but was later determined not viable due to a maximum operating temperature of 300 Celsius, half of the temperature released during thermal runaway. Instead, Pyrogel XT-E and silica fabric are being considered due to their operating temperature of 650 and 1400 Celsius. Proof of concept is still required and two experiments have been designed to test the material's flame quenching, thermal resistance, and airflow properties. However, the literature available on these materials supports the current design.

The vent prototype is shown below:

</ul>

=Validation=

Software:
<ul> Successfully Completed </ul>

Our Software library achieved the following completely: <ul> <li>The ability to transmit SBD messages to a NASA ARC associated Gmail account</li> <li>Automatically retrieve these email attachments and store them locally to our server via a python script</li> <li>Create a dial-up connection which will drop after 30 seconds</li> <li>Receive data through TES and perform various actions depending on the prefix to the message</li> <li>The ability to switch between SBD and dial-up communication modes throughout the program cycl.</li> </ul> Our software library achieved the following partially: <ul> <li>A cryptosystem class built for AES-128-bit encryption and decryption in CBC mode</li> <ul> <li>The class is built and works properly on a computer, but the decryption does not work when running on our microprocessor at the moment</li> <li>This issue would need to be fixed before being used in a flight if NASA ARC wants to decrypt messages on the board itself</li> </ul> <li>The dial-up connection can be created but may not be utilized due to the lack of a TCP/IP stack as explained earlier</li> <ul> <li>Switching to RUDICS over dial-up is a future fix to this issue as explained earlier</li> </ul> </ul>

Images showing our system output can be seen below. The first image shows the process of sending an SBD packet and the second image shows the process of configuring a dial-up connection.

Future Validation: <ul> <li>The software should be tested in a High-altitude balloon first to test how the system works while in flight vs just on the ground.</li> <li>If the onboard cryptosystem is going to be used, it should be further tested and debugged to avoid potential corruption issues while in use.</li> </ul>

Carrier Module:
<ul> Successfully Completed </ul>

<li>Re-designed components: <li>New Boost Circuit: <li>Designed with the Texas Instruments Power Designer <li>Validated that it performs as expected with LTSpice and allows for worst case (~1A) current draw <ul> <li>New PCB Layout: <li>Form factor design with 4-layer technology built overseas. <li>Upgraded SAMD51 chip: </ul> <li>Microchip provides 15 page checklist to help with the building and test against. <li>Created the power supply requirements.

Future Validation: <li>After assembling the PCB, we will test the components onsite. <li>Testing will work with the Software subteam to ensure that code working on the initial carrier module will work on the re-designed board. </ul>

Battery Containment Unit:
<ul> Incomplete due to COVID-19 </ul> A series of experiments were designed to fail li-ion batteries, determine the approximate energy released during thermal runaway, and show how thermal runaway is transferred from cell-to-cell/module-to-module. A full list of the experiments is shown below. <ul> </ul> Initial testing was conducted with a two-cell Zippy brand Li-ion batteries. To fail the battery we connected two external leads and recorded the temperature of the battery with a thermal camera. Hydrogen gas production and temperature of 135oF were observed but extreme failure was not observed due to safety measures built into the batteries. Different Li-ion batteries with fewer built-in safety measures are required in order to observe extreme failure. As a result, we ordered several single 18650 Li-ion cells from Samsung. Experiment one has four procedures where thermal runaway will occur; short circuit, overcharge, external heat, and mechanical failure. The objective of this experiment is to determine the most reliable way to fail the li-ion cell for future experiments. Experiment two would look at how thermal runaway transfers from cell to cell and module to module. One cell would e forcibly failed and data would be collected with the thermal camera. This experiment will allow us to better understand how thermal runaway transfers between the modules and will determine the critical transfer temperature. Additionally, different lining materials will be tested for their effectiveness to halt the transfer of thermal runaway between the modules. The flames produced during thermal runaway are produced by hydrogen gas burning, not oxygen/nitrogen. As a result, the flames burn hotter and may not be as effectively quenched by the metal foam as oxygen-based flames are. Experiment number three would force a li-ion cell into a thermal runaway with the metal foam placed within the produced flames. Images collected with the thermal camera would be used to measure the flame propagation through the foam. From these images, the critical flame quenching distance can be measured. Should the foams effectively quench the flames they can be utilized in the final design. To determine the amount of energy released by a single Li-ion cell during thermal runway we would have built and calibrated a "coffee cup" calorimeter. A sealed powder coated junction box would hold the cell and be submerged inside another box with room temperature water. The cell would be forced into thermal runway and the change in water temperature would be used to determine the energy released by the cell. To calibrate the calorimeter, hot water would be poured into the junction box to determine the energy absorbed by the steel. The airflow test would determine how effectively the materials would ventilate pressurized gasses. The junction box would be sealed with a burst disk calibrated to a specified pressure. The materials of interest would sit next to the burst disk. Once the disk popped the pressurized air would escape through the material of interest. The time it would take for the air inside the box to return to atmospheric pressure would be recorded. Materials with shorted depressurization time would be better at ventilating the gasses built up during thermal runaway. The ventilation prototype consisting of the metal foam and pyrogel/silica fabric will be validated with this experiment. Experimental Procedures and Calibration </ul> </ul>
 * 1) Forced Failure of 18650 Li-ion cells: </i>Development for Reproducible Failure Procedures</i>
 * 2) Transfer Mechanism of Thermal Runaway
 * 3) Flame Quenching Properties of Pyrogel and Al metal foam
 * 4) Determination of Energy Released during Thermal Runaway of Li-ion cells via Calorimetry
 * 5) Flowthrough Properties for Battery-Box Ventilation Materials

Future Validation: The experimental results from experiments two, three, and five would validate the selection of the materials for the final product. The final firebox prototype will be sent to Johnson Space Center for destructive testing to test it's resistance to mechanical failure.

=Team Members=

=Additional Documentation=

Project Schedule

Meeting Minutes

Software GitHub Page

Our Expo poster can be seen below: