Search NASA⌕ Search

SEARCH · Search NASA

Results for “instrument data processing services”

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.

At least 163 records · Page 9
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

The Mars Reconnaissance Orbiter Mission Operations: Architecture and Approach

The Mars Reconnaissance Orbiter (MRO) was launched on August 12, 2005 by an Atlas V launch vehicle from Cape Canaveral Air Force Station. MRO will carry a rich set of science instruments to Mars and provide global, regional survey, and targeted observations. In addition, a set of engineering instruments providing optical navigation, Ka band telecommunication and UHF relay services to future Mars missions are part of the MRO payload. During the mission, the MRO operations teams are presented with two major challenges - unprecedented high data rate and data volumes, and complex science planning and resource sharing. MRO has the capability to communicate with earth at a maximum of six Megabits per second (> 50 times any previous Mars missions). With the current Deep Space Network (DSN) contact schedule of 19 eight-hour tracks per week, the baseline mission plan is for MRO to return 34 Terabits of raw science data during the two year primary science phase. Each of the science instruments has its unique requirements for global mapping, regional survey, and targeted observations. Some instruments prefer nadir-only observations, while others require off-nadir observations (especially for stereo viewing). The requirements from these Mars viewing instruments presented a significant challenge for the operations team to design the complex science planning and resource sharing/allocation process. This paper describes what MRO project is implementing to solve these challenges.

Mars Reconnaissance Orbiter (MRO)↗
NASA NTRSDate not supplied

MUSTANG: A Workhorse for NASA Spaceflight Avionics

The Modular Unified Space Technology Avionics for Next Generation (MUSTANG) is a small integrated Avionics system including Command and Data Handling (C&DH), Power System Electronics (PSE), Attitude Control System Interfaces (ACS), and Propulsion Electronics. The MUSTANG Avionics Architecture is built upon many years of knowledge capture and lessons learned at the Goddard Space Flight Center. With a motivation towards modularity and keeping board redesign costs to a minimum, MUSTANG offers flexibility in features with a backplane-less design and allows the user to choose the options (cards) needed for their system. It incorporates a distributed power system that provides secondary power to all its subcomponents reducing the number of primary services needed for an Avionics. MUSTANG can be integrated into one system or divided into several smaller components. MUSTANG supports redundancy and cross-strap ability for a more robust and reliable Avionics system. A variation of MUSTANG exists for Instrument Electronics called iMUSTANG and allows the user to select functionality applicable to the instrument electronics. MUSTANG is not meant to replace Avionics for all spacecraft. There are limitations due to its relatively compact size, but the MUSTANG design has proven broadly applicable on many spacecraft and instrument bus avionics architectures.

MUSTANG↗
NASA NTRS2018

Toward a Common Earth Data Publication Framework

Data publication is an essential activity for all data archives. Each of NASA's twelve Distributed Active Archive Centers (DAACs) have established publication workflows which account for the heterogeneous suite of missions, instruments, data providers, and datasets managed within the Earth Observation System Data and Information System (EOSDIS) program. Some aspects of data publication vary across DAACs: workflows range from manual to automatic, terms used to describe publication elements differ, and systems used to publish and manage data vary. Despite these differences, the DAAC data publication processes are generally the same: obtain the data and related information from data providers, describe the data with metadata and documentation, and release the data for access by the user community. In order to improve consistency and reduce the time required to publish data, we have developed a cross-DAAC initiative called the Common Earthdata Publication Framework (Earthdata Pub). Earthdata Pub seeks to: standardize communications and interactions with data providers; identify and standardize common workflows and steps in the data publication process; and design/implement a front-end system with features that include a common web interface, email & status tracking, and common application programming interfaces (APIs) to communicate with various DAAC-specific software components (services and applications) on the back-end. We will present the latest updates on this effort's progress and future plans.

data publication↗
NASA NTRS2017

Mission Use of the SpaceCube Hybrid Data Processing System

The award-winning SpaceCube v2.0 system is a high performance, reconfigurable, hybrid data processing system that can be used in a multitude of applications including those that require a radiation hardened and reliable solution. This presentation provides an overview of the design architecture, flexibility, and the advantages of the modular SpaceCube v2.0 high performance data processing system for space applications. The current state of the proven SpaceCube technology is based on 11 years of engineering and operations. Eight systems have been successfully operated in space starting in 2008 with eight more to be delivered for payload integration in 2018 in support of various missions. This presentation will highlight how this multipurpose system is currently being used to solve design challenges of a variety of independent applications. The SpaceCube hardware adapts to new system requirements by allowing for application-unique interface cards that are utilized by reconfiguring the underlying programmable elements on the core processor card. We will show how this system is being used to improve on a heritage NASA GPS technology, enable a cutting-edge LiDAR instrument, and serve as a typical command and data handling (CDH) computer for a space robotics technology demonstration.Finally, this presentation will highlight the use of the SpaceCube v2.0 system on the Restore-L robotic satellite servicing mission. SpaceCube v2.0 is the central avionics responsible for the real-time vision system and autonomous robotic control necessary to find, capture, and service a national asset weather satellite.

Petrick, Dave↗
NASA NTRS2014

Evolution of the JPSS Ground Project Calibration and Validation System

The Joint Polar Satellite System (JPSS) is the National Oceanic and Atmospheric Administrations (NOAA) next-generation operational Earth observation Program that acquires and distributes global environmental data from multiple polar-orbiting satellites. The JPSS Program plays a critical role to NOAAs mission to understand and predict changes in weather, climate, oceans, coasts, and space environments, which supports the Nation’s economy and protection of lives and property. The National Aerospace and Atmospheric Administration (NASA) is acquiring and implementing the JPSS, comprised of flight and ground systems on behalf of NOAA. The JPSS satellites are planned to fly in the afternoon orbit and will provide operational continuity of satellite-based observations and products for NOAA Polar-orbiting Operational Environmental Satellites (POES) and the Suomi National Polar-orbiting Partnership (SNPP) satellite. To support the JPSS Calibration and Validation (CalVal) node Government Resource for Algorithm Verification, Independent Test, and Evaluation (GRAVITE) services facilitate: Algorithm Integration and Checkout, Algorithm and Product Operational Tuning, Instrument Calibration, Product Validation, Algorithm Investigation, and Data Quality Support and Monitoring. GRAVITE is a mature, deployed system that currently supports the SNPP Mission and has been in operations since SNPP launch. This paper discusses the major re-architecture for Block 2.0 that incorporates SNPP lessons learned, architecture of the system, and demonstrates how GRAVITE has evolved as a system with increased performance. It is now a robust, stable, reliable, maintainable, scalable, and secure system that supports development, test, and production strings, replaces proprietary and custom software, uses open source software, and is compliant with NASA and NOAA standards.

Data Processing↗
DOE OSTI2022

Development of a Cloud-based Application to Enable a Scalable Risk-informed Predictive Maintenance Strategy at Nuclear Power Plants

Light-water reactor operations and maintenance (O&M) costs are prohibitively high, thus contributing to the premature decommissioning of nuclear power plants (NPPs). This is partly due to how the equipment is monitored. In recent years, cloud computing has emerged as a dominant technology by virtue of its low costs, computing and storage adaptability, and ability to host applications over numerous types of virtual infrastructures. Cloud computing can be a cost-effective alternative to onsite storage and diagnostics. This paper conducts a techno-economic assessment of a provisional cloud deployment architecture for a NPP predictive monitoring (PdM) system. The cloud-based monitoring system would enable maintenance and diagnostics (M&D) analysts and other authorized plant users to remotely monitor equipment functionality so as to enable PdM practices and early detection of faults. The Microsoft Azure cloud platform is included in the proposed cloud architecture to provide data processing and storage, sensor device networking, and database management; however, this analysis could be extended to other cloud computing service providers as well. For the techno-economic assessment, technical feasibility is measured in terms of network performance metrics such as response time, latency, and throughput, whereas economic feasibility is measured in terms of operational costs and capital expenditures. Finally, this report covers certain regulatory and security aspects that may concern licensees looking to implement cloud computing. The report focuses on the integration of sensor database storage, the application of cloud resources to PdM, and the identification of technological and economic hurdles associated with moving to a cloud-computing-based architecture.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗
DOE OSTI2026

COMPASS-FME Terrestrial Ecosystem Manipulation to Probe the Effects of Storm Treatments (TEMPEST) Experiment Level 2 Sensor Data v2-1

This is the version v2-1 Level 2 (L2) data release for COMPASS-FME environmental sensors located at our Terrestrial Ecosystem Manipulation to Probe the Effects of Storm Treatments (TEMPEST) experimental site. This manipulative, ecosystem-scale TEMPEST experiment addresses the potential for freshwater and estuarine-water disturbance events to alter tree function, species composition, and ecosystem processes in a deciduous coastal forest in MD, USA. The experiment uses a large-unit (2000 m2), un-replicated experimental design, with three 50 m × 40 m plots serving as control, freshwater, and estuarine-water treatments. Level 2 (L2) data consist of sensor observations from the COMPASS-FME synoptic sites, TEMPEST, and DELUGE. Compared to the L1 data, these are more consistent (always 15-minute timestamps for the entire year); better QA/QC’d (out of bounds, out of service, and extreme outlier values are removed); and more complete, with a gap-filled time series available alongside the main observations, and additional derived (calculated) variables. L2 data are intended to be rapidly and easily usable in analyses and simulations. However, algorithmic outlier identification always carries the risk of removing valid data, and Level 1 data may be more suitable for analyses that focus on variability or extreme events. This dataset includes: - An overall dataset README file that describes the current version, gives citation and contact information, etc. - Site- and year-specific folders, each holding variable-specific Parquet (a high performance, space efficient format; see https://parquet.apache.org) data files for each site and plot in that year. - Metadata files within each site-year folder provide full information on data units, expected ranges, contact information, detailed flood times, as well as a general description of the site. - Environmental sensor types that appear in the data files include weather (ClimaVUE50, CS, RM Young, and LI instruments in the graphs below); soil conditions (TEROS12); soil redox state (Redox); groundwater variables (AquaTROLL200 and AquaTROLL600); open water sondes (Exo); tree sap velocity (Sapflow); and system voltage and state (Datalogger). Data are reported every 15 minutes. Please see v2-1 TEMPEST L2 Sensor Package Quick Start.pdf for detailed information on data package structure, temporal coverage, and versioning. Data files are in Apache Parquet, a high performance, space efficient format for tabular data. These files can be read using R's `arrow` package (https://arrow.apache.org/docs/r/), with similar tools available in other languages. The TEMPEST flood events occurred on the following dates. They lasted for ~10 hours each day and delivered ~80,000 gallons to each plot; many data streams are available at 1 or 5 minute frequency during these periods. * Tests: Aug 25 (fresh plot) and Sep 9 (salt plot), 2021 * TEMPEST 1: June 22, 2022 * TEMPEST 2: June 6-7, 2023 * TEMPEST 3: June 11-13, 2024

EARTH SCIENCE > ATMOSPHERE > ATMOSPHERIC TEMPERATU↗
DOE OSTI2024

Kubernetes for the Deep Underground Neutrino Experiment Data Acquisition

The Deep Underground Neutrino Experiment (DUNE) is a next-generation long-baseline neutrino experiment based in the USA which is expected to start taking data in 2029. DUNE aims to precisely measure neutrino oscillation parameters by detecting neutrinos from the LBNF beamline (Fermilab) at the Far Detector, 1,300 kilometres away, in South Dakota at the Sanford Underground Research Facility. The Far Detector will consist of four cryogenic Liquid Argon Time Projection Chamber detectors of 17 kT, each producing more than 1 TB/sec of data. The main requirements for the data acquisition system are the ability to run continuously for extended periods of time, with a 99% up-time requirement, and the functionality to record both beam neutrinos and low energy neutrinos from the explosion of a neighbouring supernova, should one occur during the lifetime of the experiment. The key challenges are the high data rates that the detectors generate and the deep underground environment, which places constraints on power and space. To overcome these challenges, DUNE plans to use a highly optimised C++ software suite and a server farm of about 110 nodes continuously running about two hundred multicore processes located close to the detector, 1.5 kilometres underground. Thirty nodes will be at the surface and will run around two hundred processes simultaneously. DUNE is studying the use of the Kubernetes framework to manage containerised workloads and take advantage of its resource definitions and high up-time services to run the DAQ system. Progress in deploying these systems at the CERN neutrino platform on the prototype DUNE experiments is reported.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗
NASA NTRS2006

Hubble Space Telescope 2004 Battery Update

Battery cell wear out mechanisms and signatures are examined and compared to orbital data from the six on-orbit Hubble Space Telescope (HST) batteries, and the Flight Spare Battery (FSB) Test Bed at Marshall Space Flight Center (MSFC), which is instrumented with individual cell voltage monitoring. The on-orbit HST batteries were manufactured on an expedited basis after the Challenger Shuttle Disaster in 1986. The original design called for the HST to be powered by six 50 Ah Nickel Cadmium batteries, which would have required a shuttle mission every 5 years for battery replacement. The decision to use NiH2 instead has resulted in a longer life battery set which was launched with HST in April 1990, with a design life of 7 years that has now exceeded 14+ years of orbital cycling. This chart details the specifics of the original HST NiH2 cell design. The HST replacement batteries for Service Mission 4, originally scheduled for Spring 2005, are currently in cold storage at NASA Goddard Space Flight Center (GSFC). The SM4 battery cells utilize slurry process electrodes having 80% porosity.

Hollandsworth, Roger↗
DOE OSTI2023

Driving Next-Generation Workflows from the Data Plane

We observe the emergence of a new generation of scientific workflows that process data produced at a sustained rate by scientific instruments and large scale numerical simulations. This data is consumed by multiple analysis, visualization, or Machine Learning components not only to enable inference and justify the scientific program, but also to monitor and steer the evolution of these experiments. In such workflows, moving intermediate data efficiently is key to performance, more than efficiently scheduling computational tasks. However, most traditional workflow management systems focus on optimizing task scheduling and then deal with data management, assuming a “move little, compute for long” model, which makes them unfit to the efficient management of this new generation of workflows. Therefore, we advocate for a new way to manage scientific workflows. We propose to consider an efficiently and independently managed data plane that can store and stream data. Workflows compute components, in the application plane can then interact with the data plane, abstracted from complexities of data management. Then, the role of a workflow management system would become that of a control plane that allows users to connect services together to execute the workflow and manages connections between the application and data planes. In this position paper, we characterize several next-generation workflow motifs and describe how their interaction with the data plane is a challenge to traditional workflow management systems. Then, we express a set of requirements that a workflow management system should meet to efficiently manage next-generation workflows at different scales. Based on these requirements, we expose our vision of driving next-generation workflows from the data plane and list remaining open challenges.

Suter, Fred↗
NASA NTRS2005

Giovanni: A System for Rapid Access, Visualization and Analysis of Earth Science Data Online

Collecting data and understanding data structures traditionally are the first steps that a user must take, before the core investigation can begin. This is a time-consuming and challenging task, especially when science objectives require users to deal with large multi-sensor data that are usually in different formats and internal structures. The Goddard Earth Sciences Data and Information Services Center (GES DISC) has created the GES DISC Interactive Online Visualization and ANalysis Infrastructure, Giovanni, to enable Web-based visualization and analysis of satellite remotely sensed meteorological, oceanographic, and hydrologic data sets, without users having to download data. The current operational Giovanni interfaces provide the capability to process a number of important satellite measurements, such as (1) ozone and other trace gases from TOMS, OMI, HALOE, and MLS; (2) air temperature, water vapor, and geopotential height from AIRS; (3) aerosols from MODIS TerrdAqua, and GOCART model; (4) precipitation from TRMM and ground measurements; (5) chlorophyll and other ocean color products from SeaWiFS and MODIS Aqua; and (6) sea surface temperature from MODIS Aqua. Depending on the input data structure, the system provides simple statistical analysis and creates time-averaged area plot, area-averaged time series, animations, Hovmoller latitude vs. time and longitude vs. time plots, as well as vertical profiles. The inter-comparison interfaces allow a user to compare observations from different instruments, to conduct anomaly analysis, and to study basic relationships between physical parameters. Giovanni handles data with different temporal and spatial resolutions and, thus, enables both regional and global long-term climate research and short-term special events investigation, as well as data validations and assessments. Because of its simplicity of usage, Giovanni is powerful and versatile, able to assist a wide range of users, from the discipline scientists conducting preliminary research in various fields, to students in the classroom learning about weather, climate, and other natural phenomena. Giovanni can be accessed from: http://disc. esfc.nasa.gov/techlab/giovanni/index.shtml

Shen, S.↗
NASA NTRS2017

Recovering Nimbus Era Observations at the NASA GES DISC

Between 1964 and 1978, NASA launched a series of seven Nimbus meteorological satellites which provided Earth observations for 30 years. These satellites, carrying a total of 33 instruments to observe the Earth at visible, infrared, ultraviolet, and microwave wavelengths, revolutionized weather forecasting, provided early observations of ocean color and atmospheric ozone, and prototyped location-based search and rescue capabilities. The Nimbus series paved the way for a number of currently operational systems such as the EOS (Earth Observation System) Terra, Aqua, and Aura platforms. The original data archive includes both magnetic tapes and film media. These media are well past their expected end of life, placing at risk valuable data that are critical to extending the history of Earth observations back in time. GES DISC (Goddard Earth Sciences Data and Information Services Center) has been incorporating these data into a modern online archive by recovering the digital data files from the tapes, and scanning images of the data from film strips. The digital data products were written on obsolete hardware systems in outdated file formats, and in the absence of metadata standards at that time, were often written in proprietary file structures. Through a tedious and laborious process, oft-corrupted data are recovered, and incomplete metadata and documentation are reconstructed.

data recovery↗
NASA NTRS2007

Guaranteeing Pointing Performance of the SDO Sun-Pointing Controllers in Light of Nonlinear Effects

The Solar Dynamics Observatory (SDO) mission is the first Space Weather Research Network mission, part of NASA s Living With a Star program.1 This program seeks to understand the changing Sun and its effects on the Solar System, life, and society. To this end, the SDO spacecraft will carry three Sun-observing instruments to geosynchronous orbit: Helioseismic and Magnetic Imager (HMI), led by Stanford University; Atmospheric Imaging Assembly (AIA), led by Lockheed Martin Space and Astrophysics Laboratory; and Extreme Ultraviolet Variability Experiment (EVE), led by the University of Colorado. Links describing the instruments in detail may be found through the SDO web site.2 The basic mission goals are to observe the Sun for a very high percentage of the 5-year mission (10-year goal) with long stretches of uninterrupted observations and with constant, high-data-rate transmission to a dedicated ground station. These goals guided the design of the spacecraft bus that will carry and service the three-instrument payload. At the time of this publication, the SDO spacecraft bus is well into the integration and testing phase at the NASA Goddard Space Flight Center (GSFC). A three-axis stabilized attitude control system (ACS) is needed both to point at the Sun accurately and to keep the roll about the Sun vector correctly positioned. The ACS has four reaction wheel modes and 2 thruster actuated modes. More details about the ACS in general and the control modes in particular can be found in Refs. [3-6]. All four of SDO s wheel-actuated control modes involve Sun-pointing controllers, as might be expected from such a mission. Science mode, during which most science data is collected, uses specialized guide telescopes to point accurately at the Sun. Inertial mode has two sub-modes, one tracks a Sun-referenced target orientation, and another maintains an absolute (star-referenced) target orientation, that both employ a Kalman filter to process data from a digital Sun sensor and two star trackers. However, this paper is concerned only with the other two modes: Safe Hold (SH) and Sun Acquisition (SA).

Starin, Scott R.↗
NASA NTRS2016

Evolution of the JPSS Ground Project Calibration and Validation System

The Joint Polar Satellite System (JPSS) is the National Oceanic and Atmospheric Administration's (NOAA) next-generation operational Earth observation Program that acquires and distributes global environmental data from multiple polar-orbiting satellites. The JPSS Program plays a critical role to NOAA's mission to understand and predict changes in weather, climate, oceans, coasts, and space environments, which supports the Nation's economy and protection of lives and property. The National Aeronautics and Space Administration (NASA) is acquiring and implementing the JPSS, comprised of flight and ground systems, on behalf of NOAA. The JPSS satellites are planned to fly in the afternoon orbit and will provide operational continuity of satellite-based observations and products for NOAA Polar-orbiting Operational Environmental Satellites (POES) and the Suomi National Polar-orbiting Partnership (SNPP) satellite. To support the JPSS Calibration and Validation (CalVal) node Government Resource for Algorithm Verification, Independent Test, and Evaluation (GRAVITE) services facilitate: Algorithm Integration and Checkout, Algorithm and Product Operational Tuning, Instrument Calibration, Product Validation, Algorithm Investigation, and Data Quality Support and Monitoring. GRAVITE is a mature, deployed system that currently supports the SNPP Mission and has been in operations since SNPP launch. This paper discusses the major re-architecture for Block 2.0 that incorporates SNPP lessons learned, architecture of the system, and demonstrates how GRAVITE has evolved as a system with increased performance. It is now a robust, stable, reliable, maintainable, scalable, and secure system that supports development, test, and production strings, replaces proprietary and custom software, uses open source software, and is compliant with NASA and NOAA standards.

Next-Generation↗
NASA NTRS2012

Application Programming in AWIPS II

Since its inception almost 8 years ago, NASA's Short-term Prediction Research and Transition (SPoRT) Center has integrated NASA data into the National Weather Service's decision support system (DSS) the Advanced Weather Interactive Processing System (AWIPS). SPoRT has, in some instances, had to shape and transform data sets into various formats and manipulate configurations to visualize them in AWIPS. With the advent of the next generation of DSS, AWIPS II, developers will be able to develop their own plugins to handle any type of data. Raytheon is developing AWIPS II to be a more extensible package written mainly in Java, and built around a Service Oriented Architecture. A plugin architecture will allow users to install their own code modules, and (if all the rules have been properly followed) they will work hand-in-hand with AWIPS II as if it were originally built in. Users can bring in new datasets with existing plugins, tweak plugins to handle a nuance or desired new functionality, or create an entirely new visualization layout for a new dataset. SPoRT is developing plugins to ensure its existing NASA data will be ready for AWIPS II when it is delivered, and to prepare for the future of new instruments on upcoming satellites.

Smit, Matt↗
NASA NTRS2004

User-Friendly Interface Developed for a Web-Based Service for SpaceCAL Emulations

A team at the NASA Glenn Research Center is developing a Space Communications Architecture Laboratory (SpaceCAL) for protocol development activities for coordinated satellite missions. SpaceCAL will provide a multiuser, distributed system to emulate space-based Internet architectures, backbone networks, formation clusters, and constellations. As part of a new effort in 2003, building blocks are being defined for an open distributed system to make the satellite emulation test bed accessible through an Internet connection. The first step in creating a Web-based service to control the emulation remotely is providing a user-friendly interface for encoding the data into a well-formed and complete Extensible Markup Language (XML) document. XML provides coding that allows data to be transferred between dissimilar systems. Scenario specifications include control parameters, network routes, interface bandwidths, delay, and bit error rate. Specifications for all satellite, instruments, and ground stations in a given scenario are also included in the XML document. For the SpaceCAL emulation, the XML document can be created using XForms, a Webbased forms language for data collection. Contrary to older forms technology, the interactive user interface makes the science prevalent, not the data representation. Required versus optional input fields, default values, automatic calculations, data validation, and reuse will help researchers quickly and accurately define missions. XForms can apply any XML schema defined for the test mission to validate data before forwarding it to the emulation facility. New instrument definitions, facilities, and mission types can be added to the existing schema. The first prototype user interface incorporates components for interactive input and form processing. Internet address, data rate, and the location of the facility are implemented with basic form controls with default values provided for convenience and efficiency using basic XForms operations. Because different emulation scenarios will vary widely in their component structure, more complex operations are used to add and delete facilities.

Liszka, Kathy J.↗
NASA NTRSDate not supplied

Mass Spectrometer Observing Lunar Operations (MSoLo)

Introduction: In 2019, the National Aeronautics and Space Administration (NASA) announced that it would seek to have humans return to the moon by 2024 in the hopes of establishing a more sustainable lunar presence by 2028. This goal comes with many challenges, one of upmost importance will be to utilize resources that can be found on the moon. Water, which has been identified in the lunar Polar Regions, will be a key resource for in-situ resource utilization (ISRU), as it is capable of being processed for vehicular fuel, as well as life support systems materials such as oxygen. Upcoming Commercial Lunar Payload Services (CLPS) missions will be critical for these resource assessments. Methods: A modified commercial off-the-shelf (COTS) mass spectrometer developed at Kennedy Space Center known as MSolo, consisting of a quadrupole mass filter and space rated electronics undergoes testing and modifications in order to study operational parameters to unconventional approaches needed in flight situations. In general, MSolo operates in the 0-100 m/z range with the ability to detect with a faraday cup (FC) or an electron multiplier (EM) for enhanced detection. A crossbeam (XB) ionization source is used. Preliminary Data: Prior to construction, little information was available on how the MSolo system would perform at lunar like environments, factors such as temperatures (possible fluctuations from 70 to -45 °C), vibrations from launch and their side effects, the general ability to operate while the entire system (hardware and electronic components) were in a vacuum environment, were factors that while know to flight instruments, were something new to a modified COTS system. As components start to warm up, temperature becomes a key factor (ie. heat can no longer escape the electronics as no atmosphere is present), therefore it becomes crucial to find new ways to maintain stable signals and keep the instrument tuned. Calibration itself becomes an important parameter that needs to be performed while maintaining all flight like characteristics. Even the structure itself of MSolo’s sensor needed to be changed to survive the verification parameters needed to be approved for flight. Most important, all the modifications made to the COTS system have to keep the instrument working at the same specifications of the standard commercial systems. Novel Aspect: Results gathered provide key parameters that will assist to the unconventional mass spectrometry approaches of the upcoming CLPS missions to which MSolo has been selected to.

MSolo↗
NASA NTRS1998

Spectrum Preprocessing in the OPAD System

To determine the readiness of a rocket engine, and facilitate decisions on continued use of the engine before servicing is required, high-resolution optical spectrometers are used to acquire spectra from the exhaust plume. Such instruments are in place at the Technology Test Bed (TTB) stand at Marshall Space Flight Center (MSFC) and the A1 stand at Stennis Space Center (SSC). The optical spectrometers in place have a wide wavelength range covering the visible and near-infrared regions, taking approximately 8000 measurements at about one Angstrom spacing every half second. In the early stages of this work, data analysis was done manually. A simple spectral model produced a theoretical spectrum for given amount of elements and an operator visually matched the theoretical and real spectra. Currently, extensive software is being developed to receive data from the spectrometer and automatically generate an estimate of element amounts in the plume. It will result in fast and reliable analysis, with the capability of real-time performance. This software is the result of efforts of several groups but mainly it has been developed and used by scientists and combustion engineers, in their effort of understanding the underlying physical processes and phenomena and creating visualization and report generation facilities. Most of the software has been developed using the IDL language and programming environment which allows for extensive data visualization. Although this environment has been very beneficial, the resulting programs execute very slowly and are not easily portable to more popular, real-time environments. The need for portability and high speed of execution is becoming more apparent as the software matures moving out of the experimentation stage and into the production stage where ease of use and short response time are the most desirable features. The purpose of the work described here is to assist the scientists who developed the original IDL-based version in the conversion of the software into the real-time, production version. Specifically, a section of the software devoted to the preprocessing of the spectra has been converted into the C language. In addition, parts of this software which may be improved have been identified, and recommendations are given to improve the functionality and ease of use of the new version.

Katsinis, Constantine↗