Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Separation circuit”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

364 records · Page 21

Marangoni effect and its potential utilization in supporting lunar habitats and other extraterrestrial endeavors

Tears of wine is a phenomenon frequently observed as a ring of wine formed near the top of the glass generates droplets that fall back into the wine. This phenomenon can be explained by the Marangoni effect driven by the surface tension created via gradient on concentration and temperature along with the interface between two phases. Besides being observed while drinking wine, the Marangoni effect is crucial for welding metals, manufacturing integrated circuits, and growing crystals; the Marangoni effect might be also crucial in supporting lunar habitats and other extraterrestrial endeavors as vacuum and reduced gravity are expected to augment the Marangoni effect on extraterrestrial molten soil leading to sustainable extraterrestrial in-situ resources utilization (ISRU). Preliminary Marangoni effect assessment on molten lunar regolith was conducted via JSC-1A lunar regolith simulant under vacuum yielding a spontaneous upwards migration of a uniform molten thin-film front that climbed the crucible wall covering the entire wall’s surface and reaching the crucible’s top end. A temperature gradient within the melt’s bulk and along the crucible’s wall generates a surface tension large enough not only to form a meniscus within the three-phase junction (crucible’s wall, bulk melt, and vacuum) but also to supersede the gravitational force to create the upwards migration of a thin film front originated on the meniscus. The observed extensive wettability of the melt with the crucible surface, an additional key factor besides surface tension necessary to sustain upwards migration, is atypical to what it has been witnessed on molten JSC-1A lunar regolith simulant under non-vacuum conditions and smaller sample sizes. The unique formation and self-migration of a thin-film front could enable key ISRU processes such as thin-film coating, crystal growth, and feedstock generation for additive 3D printing. Further assessment on the higher-temperature vacuum-driven decomposition of the uniform thin-film front as it climbed the crucible’s wall revealed a significant decomposition of various simulant’s metal-oxide components into their respective oxygen and metal elements strengthening the feasibility of extraterrestrial generation and fractional separation of oxygen and metals/alloys with none or minimal need for terrestrial precursors. The Marangoni effect assessment on molten JSC-1A lunar regolith simulant clearly opens novel pathways in future extraterrestrial ISRU endeavors including manufacturing and mining. Extraterrestrial mining will require an operational approach completely different from the terrestrial one that heavily relies on not only mechanical excavation and transportation but also post-processing; an in-situ all-in-one process might be feasible via these two coupled phenomena, self-migration and decomposition.

J A Dominguez↗

Laboratory-Model Integrated-System FARAD Thruster

Pulsed inductive plasma accelerators are spacecraft propulsion devices in which energy is stored in a capacitor and then discharged through an inductive coil. The device is electrodeless, inducing a plasma current sheet in propellant located near the face of the coil. The propellant is accelerated and expelled at a high exhaust velocity (order of 10 km/s) through the interaction of the plasma current with an induced magnetic field. The Faraday Accelerator with RF-Assisted Discharge (FARAD) thruster [1,2] is a type of pulsed inductive plasma accelerator in which the plasma is preionized by a mechanism separate from that used to form the current sheet and accelerate the gas. Employing a separate preionization mechanism in this manner allows for the formation of an inductive current sheet at much lower discharge energies and voltages than those found in previous pulsed inductive accelerators like the Pulsed Inductive Thruster (PIT). In a previous paper [3], the authors presented a basic design for a 100 J/pulse FARAD laboratory-version thruster. The design was based upon guidelines and performance scaling parameters presented in Refs. [4, 5]. In this paper, we expand upon the design presented in Ref. [3] by presenting a fully-assembled and operational FARAD laboratory-model thruster and addressing system and subsystem-integration issues (concerning mass injection, preionization, and acceleration) that arose during assembly. Experimental data quantifying the operation of this thruster, including detailed internal plasma measurements, are presented by the authors in a companion paper [6]. The thruster operates by first injecting neutral gas over the face of a flat, inductive acceleration coil and at some later time preionizing the gas. Once the gas is preionized current is passed through the acceleration coil, inducing a plasma current sheet in the propellant that is accelerated away from the coil through electromagnetic interaction with the time-varying magnetic field. Neutral gas is injected over the face of the acceleration coil through a fast-acting valve that feeds a central distribution manifold. The thruster is designed to preionize the gas using an RF-frequency ringing signal produced by a discharging Vector Inversion Generator (VIG). The acceleration stage consists of a multiple-turn, multiple-strand spiral induction coil (see Fig. 1, left panel) and is designed for operation at discharge energies on the order of 100 J/pulse. Several different pulsed power train modules can be used to drive current through the acceleration coil. One such power train is based upon the Bernardes and Merryman circuit topology, which restricts voltage reversal on the capacitor banks and can be clamped to eliminate current reversal in the coil. A second option is a pulse-compression-ring power train (see Fig. 1, right panel), which takesa temporally broad, low current pulse and transforms it into a short, high current pulse.

Polzin, K.A.↗

Hardware in the Loop Testing of an Iodine-Fed Hall Thruster

CUBESATS are relatively new spacecraft platforms that are typically deployed from a launch vehicle as a secondary payload,1 providing low-cost access to space for a wide range of end-users. These satellites are comprised of building blocks having dimensions of 10x10x10 cm cu and a mass of 1.33 kg (a 1-U size). While providing low-cost access to space, a major operational limitation is the lack of a propulsion system that can fit within a CubeSat and is capable of executing high delta v maneuvers. This makes it difficult to use CubeSats on missions requiring certain types of maneuvers (i.e. formation flying, spacecraft rendezvous). Recently, work has been performed investigating the use of iodine as a propellant for Hall-effect thrusters (HETs) 2 that could subsequently be used to provide a high specific impulse path to CubeSat propulsion. Iodine stores as a dense solid at very low pressures, making it acceptable as a propellant on a secondary payload. It has exceptionally high ρIsp (density times specific impulse), making it an enabling technology for small satellite near-term applications and providing the potential for systems-level advantages over mid-term high power electric propulsion options. Iodine flow can also be thermally regulated, subliming at relatively low temperature ( less than100 C) to yield I2 vapor at or below 50 torr. At low power, the measured performance of an iodine-fed HET is very similar to that of a state-of-the-art xenon-fed thruster. Just as importantly, the current-voltage discharge characteristics of low power iodine-fed and xenon-fed thrusters are remarkably similar, potentially reducing development and qualifications costs by making it possible to use an already-qualified xenon-HET PPU in an iodine-fed system. Finally, a cold surface can be installed in a vacuum test chamber on which expended iodine propellant can deposit. In addition, the temperature doesn't have to be extremely cold to maintain a low vapor pressure in the vacuum chamber (it is under 10(exp -6) torr at -75 C), making it possible to 'cryopump' the propellant with lower-cost recirculating refrigerant-based systems as opposed to using liquid nitrogen or low temperature gaseous helium cryopanels. In the present paper, we describe testing performed using an iodine-fed 200 W Hall thruster mounted to a thrust stand and operated in conjunction with MSFCs Small Projects Rapid Integration and Test Environment (SPRITE) Portable Hardware In the Loop (PHIL) hardware. This work is performed in support of the iodine satellite (iSAT) project, which aims to fly a 200-W iodine-fed thruster on a 12-U CubeSat. The SPRITE PHIL hardware allows a given vehicle to do a checkout of its avionics algorithm by allowing it to monitor and feed data to simulated sensors and effectors in a digital environment. These data are then used to determine the attitude of the vehicle and a separate computer is used to interpret the data set and visualize it using a 3D graphical interface. The PHIL hardware allows the testing of the vehicles bus by providing 'real' hardware interfaces (in the case of this test a real RS422 bus) and specific components can be modeled to show their interactions with the avionics algorithm (e.g. a thruster model). For the iSAT project the PHIL is used to visualize the operating cycle of the thruster and the subsequent effect this thrusting has on the attitude of the satellite over a given period of time. The test is controlled using software running on an Andrews Space Cortex 160 flight computer. This computer is the current baseline for a full iSAT mission. While the test could be conducted with a lab computer and software, the team chose to exercise the propulsion system with a representative CubeSat-class computer. For purposes of this test, the "flight" software monitored the propulsion and PPU systems, controlled operation of the thruster, and provided thruster state data to the PHIL simulation. Commands to operate the thruster were initiated from an operator's workstation outside the vacuum chamber and passed through the Cortex 160 to exercise portions of the flight avionics. Two custom-designed pieces of electronics hardware have been designed to operate the propellant feed system. One piece of hardware is an auxiliary board that controls a latch valve, proportional flow control valves (PFCVs) and valve heaters as well as measuring pressures, temperatures and PFCV feedback voltage. An onboard FPGA provides a serial link for issuing commands and manages all lower level input-output functions. The other piece of hardware is a power distribution board, which accepts a standard bus voltage input and converts this voltage into all the different current-voltage types required to operate the auxiliary board. These electronics boards are located in the vacuum chamber near the thruster, exposing this hardware to both the vacuum and plasma environments they would encounter during a mission, with these components communicating to the flight computer through an RS-422 interface. The auxiliary board FPGA provides a 28V MOSFET switch circuit with a 20ms pulse to open or close the iodine propellant feed system latch valve. The FPGA provides a pulse width modulation (PWM) signal to a DC/DC boost converter to produce the 12-120V needed for control of the proportional flow control valve. There are eight MOSFET-switched heating circuits in the system. Heaters are 28V and located in the latch valve, PFCV, propellant tank and propellant feed lines. Both the latch valve and PFCV have thermistors built into them for temperature monitoring. There are also seven resistance temperature device (RTD) circuits on the auxiliary board that can be used to measure the propellant tank and feedline temperatures. The signals are conditioned and sent to an analog to digital converter (ADC), which is directly commanded and controlled by the FPGA.

Polzin, Kurt A.↗

Investigating the Simulink Auto-Coding Process

Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.

Gualdoni, Matthew J.↗