SEARCH · Engineering Papers

Results for “telemetry”

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.

SourceResearch connectionFrom yearThrough year

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

At least 1,027 records · Page 57

All sources NASA NTRS DOE OSTI

NASA NTRS2006

Hyper-X (X-43A) Flight Test Range Operations Overview

The Hyper-X program flew X-43A research vehicles to hypersonic speeds over the Pacific Ocean in March and November 2004 from the Western Aeronautical Test Range, NASA Dryden Flight Research Center, Edwards, California. The program required multiple telemetry ground stations to provide continuous coverage of the captive carry, launch, boost, experiment, and descent phases of these missions. An overview is provided of vehicle telemetry and distributed assets that supported telemetry acquisition, best-source selection, radar tracking, video tracking, flight termination systems, and voice communications. Real-time data display and processing are discussed, and postflight analysis and comparison of data acquired are presented.

Lux-Baumann, Jessica↗

NASA NTRS2008

GPS Metric Tracking Unit

As Global Positioning Satellite (GPS) applications become more prevalent for land- and air-based vehicles, GPS applications for space vehicles will also increase. The Applied Technology Directorate of Kennedy Space Center (KSC) has developed a lightweight, low-cost GPS Metric Tracking Unit (GMTU), the first of two steps in developing a lightweight, low-cost Space-Based Tracking and Command Subsystem (STACS) designed to meet Range Safety's link margin and latency requirements for vehicle command and telemetry data. The goals of STACS are to improve Range Safety operations and expand tracking capabilities for space vehicles. STACS will track the vehicle, receive commands, and send telemetry data through the space-based asset, which will dramatically reduce dependence on ground-based assets. The other step was the Low-Cost Tracking and Data Relay Satellite System (TDRSS) Transceiver (LCT2), developed by the Wallops Flight Facility (WFF), which allows the vehicle to communicate with a geosynchronous relay satellite. Although the GMTU and LCT2 were independently implemented and tested, the design collaboration of KSC and WFF engineers allowed GMTU and LCT2 to be integrated into one enclosure, leading to the final STACS. In operation, GMTU needs only a radio frequency (RF) input from a GPS antenna and outputs position and velocity data to the vehicle through a serial or pulse code modulation (PCM) interface. GMTU includes one commercial GPS receiver board and a custom board, the Command and Telemetry Processor (CTP) developed by KSC. The CTP design is based on a field-programmable gate array (FPGA) with embedded processors to support GPS functions.

Source record↗

NASA NTRS2007

XML Flight/Ground Data Dictionary Management

A computer program generates Extensible Markup Language (XML) files that effect coupling between the command- and telemetry-handling software running aboard a spacecraft and the corresponding software running in ground support systems. The XML files are produced by use of information from the flight software and from flight-system engineering. The XML files are converted to legacy ground-system data formats for command and telemetry, transformed into Web-based and printed documentation, and used in developing new ground-system data-handling software. Previously, the information about telemetry and command was scattered in various paper documents that were not synchronized. The process of searching and reading the documents was time-consuming and introduced errors. In contrast, the XML files contain all of the information in one place. XML structures can evolve in such a manner as to enable the addition, to the XML files, of the metadata necessary to track the changes and the associated documentation. The use of this software has reduced the extent of manual operations in developing a ground data system, thereby saving considerable time and removing errors that previously arose in the translation and transcription of software information from the flight to the ground system.

Wright, Jesse↗

NASA NTRS2006

Automated Activation and Deactivation of a System Under Test

The MPLM Automated Activation/Deactivation application (MPLM means Multi-Purpose Logistic Module) was created with a three-fold purpose in mind: 1. To reduce the possibility of human error in issuing commands to, or interpreting telemetry from, the MPLM power, computer, and environmental control systems; 2. To reduce the amount of test time required for the repetitive activation/deactivation processes; and 3. To reduce the number of on-console personnel required for activation/ deactivation. All of these have been demonstrated with the release of the software. While some degree of automated end-item commanding had previously been performed for space-station hardware in the test environment, none approached the functionality and flexibility of this application. For MPLM activation, it provides mouse-click selection of the hardware complement to be activated, activates the desired hardware and verifies proper feedbacks, and alerts the user when telemetry indicates an error condition or manual intervention is required. For MPLM deactivation, the product senses which end items are active and deactivates them in the proper sequence. For historical purposes, an on-line log is maintained of commands issued and telemetry points monitored. The benefits of the MPLM Automated Activation/ Deactivation application were demonstrated with its first use in December 2002, when it flawlessly performed MPLM activation in 8 minutes (versus as much as 2.4 hours for previous manual activations), and performed MPLM deactivation in 3 minutes (versus 66 minutes for previous manual deactivations). The number of test team members required has dropped from eight to four, and in actuality the software can be operated by a sole (knowledgeable) system engineer.

Poff, Mark A.↗

NASA NTRS2005

Support for User Interfaces for Distributed Systems

An extensible Java(TradeMark) software framework supports the construction and operation of graphical user interfaces (GUIs) for distributed computing systems typified by ground control systems that send commands to, and receive telemetric data from, spacecraft. Heretofore, such GUIs have been custom built for each new system at considerable expense. In contrast, the present framework affords generic capabilities that can be shared by different distributed systems. Dynamic class loading, reflection, and other run-time capabilities of the Java language and JavaBeans component architecture enable the creation of a GUI for each new distributed computing system with a minimum of custom effort. By use of this framework, GUI components in control panels and menus can send commands to a particular distributed system with a minimum of system-specific code. The framework receives, decodes, processes, and displays telemetry data; custom telemetry data handling can be added for a particular system. The framework supports saving and later restoration of users configurations of control panels and telemetry displays with a minimum of effort in writing system-specific code. GUIs constructed within this framework can be deployed in any operating system with a Java run-time environment, without recompilation or code changes.

Eychaner, Glenn↗

NASA NTRS2005

Health Management Applications for International Space Station

Traditional mission and vehicle management involves teams of highly trained specialists monitoring vehicle status and crew activities, responding rapidly to any anomalies encountered during operations. These teams work from the Mission Control Center and have access to engineering support teams with specialized expertise in International Space Station (ISS) subsystems. Integrated System Health Management (ISHM) applications can significantly augment these capabilities by providing enhanced monitoring, prognostic and diagnostic tools for critical decision support and mission management. The Intelligent Systems Division of NASA Ames Research Center is developing many prototype applications using model-based reasoning, data mining and simulation, working with Mission Control through the ISHM Testbed and Prototypes Project. This paper will briefly describe information technology that supports current mission management practice, and will extend this to a vision for future mission control workflow incorporating new ISHM applications. It will describe ISHM applications currently under development at NASA and will define technical approaches for implementing our vision of future human exploration mission management incorporating artificial intelligence and distributed web service architectures using specific examples. Several prototypes are under development, each highlighting a different computational approach. The ISStrider application allows in-depth analysis of Caution and Warning (C&W) events by correlating real-time telemetry with the logical fault trees used to define off-nominal events. The application uses live telemetry data and the Livingstone diagnostic inference engine to display the specific parameters and fault trees that generated the C&W event, allowing a flight controller to identify the root cause of the event from thousands of possibilities by simply navigating animated fault tree models on their workstation. SimStation models the functional power flow for the ISS Electrical Power System and can predict power balance for nominal and off-nominal conditions. SimStation uses realtime telemetry data to keep detailed computational physics models synchronized with actual ISS power system state. In the event of failure, the application can then rapidly diagnose root cause, predict future resource levels and even correlate technical documents relevant to the specific failure. These advanced computational models will allow better insight and more precise control of ISS subsystems, increasing safety margins by speeding up anomaly resolution and reducing,engineering team effort and cost. This technology will make operating ISS more efficient and is directly applicable to next-generation exploration missions and Crew Exploration Vehicles.

Alena, Richard↗

NASA NTRS2012

Revamping Spacecraft Operational Intelligence with Splunk

So what is Splunk? Instead of giving the technical details, which you can find online, I'll tell you what it did for me. Splunk slapped everything into one place, with one uniform format, and gave me the ability to forget about all these annoying details of where it is, how to parse it, and all that. Instead, I only need to interact with Splunk to find the data I need. This sounds simple and obvious, but it's surprising what you can do once you all of your data is indexed in one place. By having your data organized, querying becomes much easier. Let's say that I want to search telemetry for a sensor_name gtemp_1 h and to return all data that is at most five minutes old. And because Splunk can hook into a real ]time stream, this data will always be up-to-date. Extending the previous example, I can now aggregate all types of data into one view based in time. In this picture, I've got transaction logs, telemetry, and downlinked files all in one page, organized by time. Even though the raw data looks completely than this, I've defined interfaces that transform it into this uniform format. This gives me a more complete picture for the question what was the spacecraft doing at this particular time? And because querying data is simple, I can start with a big block of data and whiddle it down to what I need, rather than hunting around for the individual pieces of data that I need. When we have all the data we need, we can begin widdling down the data with Splunk's Unix-like search syntax. These three examples highlights my trial-and-error attempts to find large temperature changes. I begin by showing the first 5 temperatures, only to find that they're sorted chronologically, rather than from highest temperatures to lowest temperatures. The next line shows sorting temperatures by their values, but I find that that fs not really what I want either. I want to know the delta temperatures between readings. Looking through Splunk's user manual, I find the delta function, which lets me dynamically generate new information to use in my query. With that extra piece of information, I can now return only the telemetry readings where the temperature changed by at least 10. One other useful feature I'll mention is that all of these queries can be run through Splunk's API. So any scripting language you can think of can plug right in and make these queries. This gives us the ability to build a lot of new tools.

operational intelligence↗

NASA NTRS2014

Use of Semi-Autonomous Tools for ISS Commanding and Monitoring

As the International Space Station (ISS) has moved into a utilization phase, operations have shifted to become more ground-based with fewer mission control personnel monitoring and commanding multiple ISS systems. This shift to fewer people monitoring more systems has prompted use of semi-autonomous console tools in the ISS Mission Control Center (MCC) to help flight controllers command and monitor the ISS. These console tools perform routine operational procedures while keeping the human operator "in the loop" to monitor and intervene when off-nominal events arise. Two such tools, the Pre-positioned Load (PPL) Loader and Automatic Operators Recorder Manager (AutoORM), are used by the ISS Communications RF Onboard Networks Utilization Specialist (CRONUS) flight control position. CRONUS is responsible for simultaneously commanding and monitoring the ISS Command & Data Handling (C&DH) and Communications and Tracking (C&T) systems. PPL Loader is used to uplink small pieces of frequently changed software data tables, called PPLs, to ISS computers to support different ISS operations. In order to uplink a PPL, a data load command must be built that contains multiple user-input fields. Next, a multiple step commanding and verification procedure must be performed to enable an onboard computer for software uplink, uplink the PPL, verify the PPL has incorporated correctly, and disable the computer for software uplink. PPL Loader provides different levels of automation in both building and uplinking these commands. In its manual mode, PPL Loader automatically builds the PPL data load commands but allows the flight controller to verify and save the commands for future uplink. In its auto mode, PPL Loader automatically builds the PPL data load commands for flight controller verification, but automatically performs the PPL uplink procedure by sending commands and performing verification checks while notifying CRONUS of procedure step completion. If an off-nominal condition occurs during procedure execution, PPL Loader notifies CRONUS through popup messages, allowing CRONUS to examine the situation and choose an option of how PPL loader should proceed with the procedure. The use of PPL Loader to perform frequent, routine PPL uplinks offloads CRONUS to better monitor two ISS systems. It also reduces procedure performance time and decreases risk of command errors. AutoORM identifies ISS communication outage periods and builds commands to lock, playback, and unlock ISS Operations Recorder files. Operation Recorder files are circular buffer files of continually recorded ISS telemetry data. Sections of these files can be locked from further writing, be played back to capture telemetry data that occurred during an ISS loss of signal (LOS) period, and then be unlocked for future recording use. Downlinked Operation Recorder files are used by mission support teams for data analysis, especially if failures occur during LOS. The commands to lock, playback, and unlock Operations Recorder files are encompassed in three different operational procedures and contain multiple user-input fields. AutoORM provides different levels of automation for building and uplinking the commands to lock, playback, and unlock Operations Recorder files. In its automatic mode, AutoORM automatically detects ISS LOS periods, then generates and uplinks the commands to lock, playback, and unlock Operations Recorder files when MCC regains signal with ISS. AutoORM also features semi-autonomous and manual modes which integrate CRONUS more into the command verification and uplink process. AutoORMs ability to automatically detect ISS LOS periods and build the necessary commands to preserve, playback, and release recorded telemetry data greatly offloads CRONUS to perform more high-level cognitive tasks, such as mission planning and anomaly troubleshooting. Additionally, since Operations Recorder commands contain numerical time input fields which are tedious for a human to manually build, AutoORM's ability to automatically build commands reduces operational command errors. PPL Loader and AutoORM demonstrate principles of semi-autonomous operational tools that will benefit future space mission operations. Both tools employ different levels of automation to perform simple and routine procedures, thereby offloading human operators to perform higher-level cognitive tasks. Because both tools provide procedure execution status and highlight off-nominal indications, the flight controller is able to intervene during procedure execution if needed. Semi-autonomous tools and systems that can perform routine procedures, yet keep human operators informed of execution, will be essential in future long-duration missions where the onboard crew will be solely responsible for spacecraft monitoring and control.

Brzezinski, Amy S.↗

NASA NTRS2014

Applying Motion Constraints Based on Test Data

MSC ADAMS is a simulation software that is used to analyze multibody dynamics. Using user subroutines, it is possible to apply motion constraints to the rigid bodies so that they match the motion profile collected from test data. This presentation describes the process of taking test data and passing it to ADAMS using user subroutines, and uses the Morpheus free-flight 4 test as an example of motion data used for this purpose. Morpheus is the name of a prototype lander vehicle built by NASA that serves as a test bed for various experimental technologies (see backup slides for details) MSC.ADAMS"TM" is used to play back telemetry data (vehicle orientation and position) from each test as the inputs to a 6-DoF general motion constraint (details in backup slides) The MSC.ADAMS"TM" playback simulations allow engineers to examine and analyze flight trajectory as well as observe vehicle motion from any angle and at any playback speed. This facilitates the development of robust and stable control algorithms, increasing reliability and reducing development costs of this developmental engine The simulation also incorporates a 3D model of the artificial hazard field, allowing engineers to visualize and measure performance of the developmental autonomous landing and hazard avoidance technology ADAMS is a multibody dynamics solver. It uses forces, constraints, and mass properties to numerically integrate equations of motion. The ADAMS solver will ask the motion subroutine for position, velocity, and acceleration values at various time steps. Those values must be continuous over the whole time domain. Each degree of freedom in the telemetry data can be examined separately; however, linear interpolation of the telemetry data is invalid, since there will be discontinuities in velocity and acceleration.

Burlone, Michael↗

NASA NTRS2012

Entry, Descent, and Landing Communications for the 2011 Mars Science Laboratory

The Mars Science Laboratory (MSL), established as the most advanced rover to land on the surface of Mars to date, launched on November 26th, 2011 and arrived to the Martian Gale Crater during the night of August 5th, 2012 (PDT). MSL will investigate whether the landing region was ever suitable to support carbon-based life, and examine rocks, soil, and the atmosphere with a sophisticated suite of tools. This paper addresses the flight system requirement by which the vehicle transmitted indications of the following events using both X-band tones and UHF telemetry to allow identification of probable root causes should a mission anomaly have occurred: Heat-Rejection System (HRS) venting, completion of the cruise stage separation, turn to entry attitude, atmospheric deceleration, bank angle reversal commanded, parachute deployment, heatshield separation, radar ground acquisition, powered descent initiation, rover separation from the descent stage, and rover release. During Entry, Descent, and Landing (EDL), the flight system transmitted a UHF telemetry stream adequate to determine the state of the spacecraft (including the presence of faults) at 8 kbps initiating from cruise stage separation through at least one minute after positive indication of rover release on the surface of Mars. The flight system also transmitted X-band semaphore tones from Entry to Landing plus one minute although since MSL was occulted, as predicted, by Mars as seen from the Earth, Direct-To-Earth (DTE) communications were interrupted at approximately is approx. 5 min after Entry ( approximately 130 prior to Landing). The primary data return paths were through the Deep Space Network (DSN) for DTE and the existing Mars network of orbiting assets for UHF, which included the Mars Reconnaissance Orbiter (MRO), Mars Odyssey (ODY), and Mars Express (MEX) elements. These orbiters recorded the telemetry data stream and returned it back to Earth via the DSN. The paper also discusses the total power received during EDL and the robustness of the telecom design strategy used to ensure EDL communications coverage.

relay operations↗

NASA NTRS2015

Tactically Extensible and Modular Communications - X-Band TEMCOM-X

This paper will discuss a proposed CubeSat size (3U) telemetry system concept being developed at Marshall Space Flight Center (MSFC) in cooperation with the U.S. Department of the Army and Dynetics Corporation. This telemetry system incorporates efficient, high-bandwidth communications by developing flight-ready, low-cost, Protoflight software defined radio (SDR) and Electronically Steerable Patch Array (ESPA) antenna subsystems for use on platforms as small as CubeSats and unmanned aircraft systems (UASs). The current telemetry system is slightly larger in dimension of footprint than required to fit within a 0.5U CubeSat volume. Extensible and modular communications for CubeSat technologies will partially mitigate current capability gaps between traditional strategic space platforms and lower-cost small satellite solutions. Higher bandwidth capacity will enable high-volume, low error-rate data transfer to and from tactical forces or sensors operating in austere locations (e.g., direct imagery download, unattended ground sensor data exfiltration, interlink communications), while also providing additional bandwidth and error correction margin to accommodate more complex encryption algorithms and higher user volume.

Sims, William Herbert↗

NASA NTRS2015

High Data Rates for AubieSat-2 A & B, Two CubeSats Performing High Energy Science in the Upper Atmosphere

This paper will discuss a proposed CubeSat size (3 Units / 6 Units) telemetry system concept being developed at Marshall Space Flight Center (MSFC) in cooperation with Auburn University. The telemetry system incorporates efficient, high-bandwidth communications by developing flight-ready, low-cost, PROTOFLIGHT software defined radio (SDR) payload for use on CubeSats. The current telemetry system is slightly larger in dimension of footprint than required to fit within a 0.75 Unit CubeSat volume. Extensible and modular communications for CubeSat technologies will provide high data rates for science experiments performed by two CubeSats flying in formation in Low Earth Orbit. The project is a collaboration between the University of Alabama in Huntsville and Auburn University to study high energy phenomena in the upper atmosphere. Higher bandwidth capacity will enable high-volume, low error-rate data transfer to and from the CubeSats, while also providing additional bandwidth and error correction margin to accommodate more complex encryption algorithms and higher user volume.

Sims, William H.↗

NASA NTRS2015

Programmable Ultra-Lightweight System Adaptable Radio

The programmable ultra-lightweight system adaptable radio (PULSAR) is a NASA Marshall Space Flight Center transceiver designed for the CubeSat market, but has the potential for other markets. The PULSAR project aims to reduce size, weight, and power while increasing telemetry data rate. The current version of the PULSAR has a mass of 2.2 kg and a footprint of 10.8 cm2. The height depends on the specific configuration. The PULSAR S-Band Communications Subsystem is an S- and X-band transponder system comprised of a receiver/detector (receiver) element, a transmitter element(s), and related power distribution, command, control, and telemetry element for operation and information interfaces. It is capable of receiving commands, encoding and transmitting telemetry, as well as providing tracking data in a manner compatible with Earthbased ground stations, near Earth network, and deep space network station resources. The software-defined radio's (SDR's) data format characteristics can be defined and reconfigured during spaceflight or prior to launch. The PULSAR team continues to evolve the SDR to improve the performance and form factor to meet the requirements that the CubeSat market space requires. One of the unique features is that the actual radio design can change (somewhat), but not require any hardware modifications due to the use of field programmable gate arrays.

Werkheiser, Arthur↗

NASA NTRS2015

Inflight Characterization of the Cassini Spacecraft Propellant Slosh and Structural Frequencies

While there has been extensive theoretical and analytical research regarding the characterization of spacecraft propellant slosh and structural frequencies, there have been limited studies to compare the analytical predictions with measured flight data. This paper uses flight telemetry from the Cassini spacecraft to get estimates of high-g propellant slosh frequencies and the magnetometer boom frequency characteristics, and compares these values with those predicted by theoretical works. Most Cassini attitude control data are available at a telemetry frequency of 0.5 Hz. Moreover, liquid sloshing is attenuated by propellant management device and attitude controllers. Identification of slosh and structural frequency are made on a best-effort basis. This paper reviews the analytical approaches that were used to predict the Cassini propellant slosh frequencies. The predicted frequencies are then compared with those estimated using telemetry from selected Cassini burns where propellant sloshing was observed (such as the Saturn Orbit Insertion burn). Determination of the magnetometer boom structural frequency is also discussed.

Lee, Allan Y.↗

NASA NTRS2015

Inflight Characterization of the Cassini Spacecraft Propellant Slosh and Structural Frequencies

Lee, Allan Y.↗

NASA NTRS2016

Thomas Leps Internship Abstract

An optical navigation system is being flown as the backup system to the primary Deep Space Network telemetry for navigation and guidance purposes on Orion. This is required to ensure Orion can recover from a loss of communication, which would simultaneously cause a loss of DSN telemetry. Images taken of the Moon and Earth are used to give range and position information to the navigation computer for trajectory calculations and maneuver execution. To get telemetry data from these images, the size and location of the moon need to be calculated with high accuracy and precision. The reentry envelope for the Orion EM-1 mission requires the centroid and radius of the moon images to be determined within 1/3 of a pixel 3 sigma. In order to ensure this accuracy and precision can be attained, I was tasked with building precise dot grid images for camera calibration as well as building a hardware in the loop test stand for flight software and hardware proofing. To calibrate the Op-Nav camera a dot grid is imaged with the camera, the error between the image dot location and the actual dot location can be used to build a distortion map of the camera and lens system so that images can be fixed to display truth locations. To build the dot grid images I used the Electro Optics Lab optical bench Bright Object Simulator System, and gimbal. The gimbal was slewed to a series of elevations and azimuths. An image of the collimated single point light source was then taken at each position. After a series of 99 images were taken at different locations the single light spots were extracted from each image and added to a composite image containing all 99 points. During the development of these grids it was noticed that an intermittent error in the artificial "star" locations occurred. Prior to the summer this error was attributed to the gimbal having glitches in it's pointing direction and was going to be replaced, however after further examining the issue I determined it to be a software issue. I have since narrowed the likely source of the error down to a Software Development Kit released by the camera supplier PixeLink. I have since developed a workaround in order to build star grids for calibration until the software bug can be isolated and fixed. I was also tasked with building a Hardware in the Loop test stand in order to test the full Op-Nav system. A 4k screen displays simulated Lunar and Terrestrial images from a possible Orion trajectory. These images are then projected through a collimator and then captured with an Op-Nav camera controlled by an Intel NUC computer running flight software. The flight software then analyzes the images to determine attitude and position, this data is then reconstructed into a trajectory and matched to the simulated trajectory in order to determine the accuracy of the attitude and position estimates. In order for the system to work it needs to be precisely and accurately aligned. I developed an alignment procedure that allows the screen, collimator and camera to be squared, centered and collinear with each other within a micron spatially and 5 arcseconds in rotation. I also designed a rigid mount for the screen that was machined on site in Building 10 by another intern. While I was working in the EOL we received a $500k Orion startracker for alignment procedure testing. Due to my prior experience in electronics development, as an ancillary duty, I was tasked with building the cables required to operate and power the startracker. If any errors are made building these cables the startracker would be destroyed, I was honored that the director of the lab entrusted such a critical component with me. This internship has cemented my view on public space exploration. I always preferred public sector to privatization because, as a scientist, the most interesting aspects of space for me are not necessarily the most profitable. I was concerned that the public sector was faltering however, and that in order to improve human space exploration I would be forced into private sector. I now know that, at least at JSC, human spaceflight is still progressing, and exciting work is still being done. I am now actively seeking employment at JSC after I complete my Ph.D and have met with my branch chiefs and mentor to discuss transitioning to a grad Co-op position.

Leps, Thomas↗

NASA NTRS2016

HTML 5 Displays for On-Board Flight Systems

During my Internship at NASA in the summer of 2016, I was assigned to a project which dealt with developing a web-server that would display telemetry and other system data using HTML 5, JavaScript, and CSS. By doing this, it would be possible to view the data across a variety of screen sizes, and establish a standard that could be used to simplify communication and software development between NASA and other countries. Utilizing a web- approach allowed us to add in more functionality, as well as make the displays more aesthetically pleasing for the users. When I was assigned to this project my main task was to first establish communication with the current display server. This display server would output data from the on-board systems in XML format. Once communication was established I was then asked to create a dynamic telemetry table web page that would update its header and change as new information came in. After this was completed, certain minor functionalities were added to the table such as a hide column and filter by system option. This was more for the purpose of making the table more useful for the users, as they can now filter and view relevant data. Finally my last task was to create a graphical system display for all the systems on the space craft. This was by far the most challenging part of my internship as finding a JavaScript library that was both free and contained useful functions to assist me in my task was difficult. In the end I was able to use the JointJs library and accomplish the task. With the help of my mentor and the HIVE lab team, we were able to establish stable communication with the display server. We also succeeded in creating a fully dynamic telemetry table and in developing a graphical system display for the advanced modular power system. Working in JSC for this internship has taught me a lot about coding in JavaScript and HTML 5. I was also introduced to the concept of developing software as a team, and exposed to the different types of programs that are used to simplify team coding such as GitLab. While in JSC, I took full advantage of and attended the lectures that were held here on site. I learned a lot about what it is NASA does and about the interesting projects that are conducted here. One of the lectures I attended was about the selection process and the criteria that is used to select future astronauts for flight missions. This truly had an impact on my future plans as it showed me that this path was a viable option for me. After this internship I plan on completing my undergraduate course work and plan to move on for a masters degree. However, during the time in which I will be completing my masters course work, I would like to apply for the NASA pathways graduate program and, if I am accepted, eventually move on to being a full time civil servant. Working in NASA has not only been enjoyable, but full of information and great experiences that have motivated me to seek a full time employment here in the near future.

Silva, Chandika↗

NASA NTRS2018

Ammonia Vent of the External Active Thermal Control System (EATCS) Radiator #3 Flow Path #2 on the International Space Station (ISS)

The External Active Thermal Control System (EATCS) provides cooling for all pressurized modules and the main Power Distribution Electronics (PDE) on the International Space Station (ISS). There are 2 EATCS loops (Loop A and Loop B) which includes 3 deployable radiators. Each deployable radiator contains 2 flow paths to provide heat rejection.Telemetry monitoring identified a coolant (liquid ammonia) leak in EATCS Loop B. Robotic External Leak Locator (RELL) scans found higher concentrations of vaporous ammonia near the EATCS Loop B Radiator #3 Flow Path #2. On May 3, 2017, the EATCS Loop B Radiator #3 Flow Path #2 was isolated and vented. As of the data to date, the ammonia leak has ceased. The purpose of this presentation is to discuss the analysis for venting the EATCS Loop B Radiator #3 Flow Path #2. Venting analysis is performed to determine the worst case time to empty the flow path and maximum thrusts imposed on the ISS. Flight controllers and engineers in the Mission Control Center (MCC) uses this data to develop operational procedures and perform the vent safely. It was predicted that the worst case time to empty the EATCS Loop B Radiator #3 Flow Path #2 was ~ 60 minutes. The predicted maximum thrusts were ~ 11 lbf (49 N) at the start of the vent and ~10 lbf (45 N) after the system reaches saturation.The vent was successfully performed and took ~ 20 minutes to empty the EATCS Loop B Radiator #3 Flow Path #2. Using telemetry from the day of the vent, analysis determined the time to empty the EATCS Loop B Radiator #3 Flow Path #2 would be ~13 minutes. The predictive analysis used worst case inputs and assumptions which bounded the actual results. Telemetry is not available to correlate actual thrust with the predicted maximum thrusts. However, by using Russian Thrusters for ISS attitude control, attitude control telemetry indicated the flight attitude was maintained.

Cowan, Darnell T.↗