SEARCH · Search NASA

Results for “telemetry interpretation”

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.

49 records · Page 3

All sources NASA NTRS DOE OSTI

NASA NTRS1980

Data transport concepts for future NASA spacecraft

The anticipated increase in data quantity from NASA spacecraft over the next decade is expected to far exceed the capability of the present NASA data/information system to effectively manage and process that data. Conceptual designs aimed at providing more responsive and cost-effective methods for transporting and interpreting space-generated data are presented. Details of the Modular Data Transport System (MDTS) and Ancillary Data and Support Computing (ADSC) efforts done under the NASA End-to-End Data System (NEEDS) program are discussed. The common 'thread' throughout the data transport process involves the use of packet telemetry. Characteristics and benefits of packet telemetry are presented along with a discussion of techniques for generating and advantages of including ancillary data in each packet.

Lord, D. D.↗

NASA NTRS2005

Virtual Machine Language

Virtual Machine Language (VML) is a mission-independent, reusable software system for programming for spacecraft operations. Features of VML include a rich set of data types, named functions, parameters, IF and WHILE control structures, polymorphism, and on-the-fly creation of spacecraft commands from calculated values. Spacecraft functions can be abstracted into named blocks that reside in files aboard the spacecraft. These named blocks accept parameters and execute in a repeatable fashion. The sizes of uplink products are minimized by the ability to call blocks that implement most of the command steps. This block approach also enables some autonomous operations aboard the spacecraft, such as aerobraking, telemetry conditional monitoring, and anomaly response, without developing autonomous flight software. Operators on the ground write blocks and command sequences in a concise, high-level, human-readable programming language (also called VML ). A compiler translates the human-readable blocks and command sequences into binary files (the operations products). The flight portion of VML interprets the uplinked binary files. The ground subsystem of VML also includes an interactive sequence- execution tool hosted on workstations, which runs sequences at several thousand times real-time speed, affords debugging, and generates reports. This tool enables iterative development of blocks and sequences within times of the order of seconds.

Grasso, Christopher↗

NASA NTRS2009

Space Flight Plasma Data Analysis

This slide presentation reviews a method to analyze the plasma data that is reported on board the International Space station (ISS). The Floating Potential Measurement Unit (FPMU), the role of which is to obtain floating potential and ionosphere plasma measurements for validation of the ISS charging model, assess photo voltaic array variability and interpreting IRI predictions, is composed of four probes: Floating Potential Probe (FPP), Wide-sweep Langmuir Probe (WLP), Narrow-sweep Langmuir Probe (NLP) and the Plasma Impedance Probe (PIP). This gives redundant measurements of each parameter. There are also many 'boxes' that the data must pass through before being captured by the ground station, which leads to telemetry noise. Methods of analysis for the various signals from the different sets are reviewed. There is also a brief discussion of LP analysis of Low Earth Orbit plasma simulation source.

Wright, Kenneth H.↗

NASA NTRS2006

Developing Signal-Pattern-Recognition Programs

Pattern Interpretation and Recognition Application Toolkit Environment (PIRATE) is a block-oriented software system that aids the development of application programs that analyze signals in real time in order to recognize signal patterns that are indicative of conditions or events of interest. PIRATE was originally intended for use in writing application programs to recognize patterns in space-shuttle telemetry signals received at Johnson Space Center's Mission Control Center: application programs were sought to (1) monitor electric currents on shuttle ac power busses to recognize activations of specific power-consuming devices, (2) monitor various pressures and infer the states of affected systems by applying a Kalman filter to the pressure signals, (3) determine fuel-leak rates from sensor data, (4) detect faults in gyroscopes through analysis of system measurements in the frequency domain, and (5) determine drift rates in inertial measurement units by regressing measurements against time. PIRATE can also be used to develop signal-pattern-recognition software for different purposes -- for example, to monitor and control manufacturing processes.

Shelton, Robert O.↗

NASA NTRS1999

Work on Planetary Atmospheres and Planetary Atmosphere Probes

A major objective of the grant was to complete the fabrication, test, and evaluation of the atmosphere structure experiment on the Galileo Probe, and to receive, analyze, and interpret data received from the spacecraft. The grantee was competitively selected to be Principal Investigator of Jupiter's atmosphere structure on the Galileo Probe. His primary motivation was to learn as much as possible about Jupiter's atmosphere by means of a successful atmosphere structure experiment, and to support the needs and schedule of the Galileo Project. After a number of launch delays, the Flight instrument was shipped to Kennedy Space Center 2 years after the start of this collaboration, on April 14, 1989, at which time it was determined from System level tests of the ASI on the Probe that the instrument was in good working order and ready for flight. The spacecraft was launched on October 18, 1989. Data analysis of test and calibration data taken over a period of years of instrument testing was continued in preparation for the encounter. The initial instrument checkout in space was performed on October 26, 1989. The data set received by telemetry was thoroughly analyzed, and a report of the findings was transmitted to the Probe Operations Office on Feb. 28, 1990. Key findings reported were that the accelerometer biases had shifted by less than 1 mg through launch and since calibration at Bell Aerospace in 1983; accelerometer scale factors, evaluated by means of calibration currents, fell on lines of variation with temperature established in laboratory calibrations; pressure sensor offsets, correlated as a function of temperature, fell generally within the limits of several years of ground test data; atmospheric and engineering temperature sensor data were internally consistent within a few tenths of a degree; and the instrument electronics performed all expected functions without any observable fault. Altogether, this checkout was highly encouraging of the prospects of instrument performance, although performed greater than 5 years prior to Jupiter encounter. Capability of decoding the science data from the Experiment Data Record to be provided at encounter was developed and exercised using the tape recording of the first Cruise Checkout data. A team effort was organized to program the selection and combination of data words defining pressure, temperature, acceleration, turbulence, and engineering quantities; to apply decalibration algorithms to convert readings from digital numbers to physical quantities; and to organize the data into a suitable printout. A paper on the Galileo Atmosphere Structure Instrument was written and submitted for publication in a special issue of Space Science Reviews. At the Journal editor's request, the grantee reviewed other Probe instrument papers submitted for this special issue. Calibration data were carefully taken for all experiment sensors and accumulated over a period of 10 years. The data were analyzed, fitted with algorithms, and summarized in a calibration report for use in analyzing and interpreting data returned from Jupiter's atmosphere. The sensors included were the primary science pressure, temperature, and acceleration sensors, and the supporting engineering temperature sensors. This report was distributed to experiment coinvestigators and the Probe Project Office.

Seiff, Alvin↗

NASA NTRS2010

The Next Generation of Ground Operations Command and Control; Scripting in C no. and Visual Basic

Scripting languages have become a common method for implementing command and control solutions in space ground operations. The Systems Test and Operations Language (STOL), the Huntsville Operations Support Center (HOSC) Scripting Language Processor (SLP), and the Spacecraft Control Language (SCL) offer script-commands that wrap tedious operations tasks into single calls. Since script-commands are interpreted, they also offer a certain amount of hands-on control that is highly valued in space ground operations. Although compiled programs seem to be unsuited for interactive user control and are more complex to develop, Marshall Space flight Center (MSFC) has developed a product called the Enhanced and Redesign Scripting (ERS) that makes use of the graphical and logical richness of a programming language while offering the hands-on and ease of control of a scripting language. ERS is currently used by the International Space Station (ISS) Payload Operations Integration Center (POIC) Cadre team members. ERS integrates spacecraft command mnemonics, telemetry measurements, and command and telemetry control procedures into a standard programming language, while making use of Microsoft's Visual Studio for developing Visual Basic (VB) or C# ground operations procedures. ERS also allows for script-style user control during procedure execution using a robust graphical user input and output feature. The availability of VB and C# programmers, and the richness of the languages and their development environment, has allowed ERS to lower our "script" development time and maintenance costs at the Marshall POIC.

Ritter, George↗

NASA NTRSDate not supplied

A Science-Focused Artificial Intelligence (AI) Responding in Real-Time to New Information: Capability Demonstration for Ocean World Missions

Introduction: Artificial intelligence (AI) has long been considered a potential mechanism to explore increasingly challenging environments, including those with extreme temperatures and pressures, limited communication capabilities, or those with demanding terrain. We posit that missions in extreme environments could deploy an onboard AI focused on science observations and goals in order to augment a traditional concept(s) of operations (ConOps). An onboard AI capability could perform functions such as data analysis in order to make high-level decisions, including prioritized data transmission for analysis by ground-based teams or autonomously-guided follow-on analyses that maximize science return. Such a capability would empower missions to respond to scientific data of interest in real-time; a mission could make observations and perform a preliminary analysis to alert ground-based scientists to an observation of interest, enabling an informed, rapid response from Earth-based teams. Enceladus Case Study for Onboard AI: We are developing an onboard AI capability for real-time telemetry response that formulates and carries-out informed decisions in service to established mission goals, enabling increased science return of a mission. We focus our AI development for use on a constellation of SmallSats orbiting Enceladus. Our Enceladus case study tests autonomous decision-making capabilities in scenarios with complex orbital dynamics, plume ejecta, extreme cold environments, power restrictions, and a requirement to maximize science return for a potential positive detection of life, while critically evaluating the potential for false positives. Telemetry includes simulated scientific data, spacecraft onboard operational data (e.g., position, velocity, and rotation), and engineering hardware performance data. Enceladus SmallSat Constellation. Our constellation includes eight SmallSat spacecraft in an 8:35 resonant orbit-based formation, leveraging Saturn’s gravitational forces to maintain stable orbits with global coverage around Enceladus. To our knowledge, we simulate the first stable configuration of multiple spacecraft in closed orbits around Enceladus, using a full ephemeris force model (Russell and Lara, 2009). Each spacecraft’s orbit will precess, causing an eastward ground track shift (from an orbiter’s perspective) of each spacecraft for each orbit. However, all spacecraft return to their original positions relative to Enceladus after eight Enceladus revolutions around Saturn. We model communication pathways between SmallSats to understand how information would need to be transmitted across the constellation to enable AI-driven decision-making and resource allocation across the fleet. Capability Demonstration. Our simulated capability demonstration inputs position, velocity, and rotation telemetry from our Enceladus-focused constellation simulations, and mass spectrometry data collected from abiotic and biotic laboratory-analog ocean world experiments (Theiling et al., 2018; Theiling, 2021; Da Poian et al., 2023). Data from these experiments are used to simulate MS measurements and different scenarios of science observations for onboard analysis performed on each of the eight spacecraft. For these demonstrations, we integrate 24 machine learning (ML) algorithms into an onboard intelligence as a ‘knowledge base’, including algorithms evaluating data quality and those predicting (with % confidence) gas composition, ocean aqueous chemistry, and whether the sample was influenced by microbial life. The onboard AI capability is designed to use the knowledge base to come to a consensus-based decision in the interpretation of the observed data in order to request additional action outside of a pre-defined ConOps. Requested actions could include e.g., prioritized downlink to Earth (for analysis by ground-based teams) or follow-on analyses performed across the constellation. The spacecraft’s intelligent onboard planner must then determine whether sufficient resources (e.g., time, power, etc.) are available and weigh the request with mission priorities. In our simulation, the constellation is able to identify potential biosignatures using onboard ML algorithms, evaluate the confidence of that prediction, and perform follow-on analyses across the fleet to confirm the detection, in order to best prepare a transmission of these data to Earth-based teams.

astrobiology↗

NASA NTRS1994

Table-driven configuration and formatting of telemetry data in the Deep Space Network

With a restructured software architecture for telemetry system control and data processing, the NASA/Deep Space Network (DSN) has substantially improved its ability to accommodate a wide variety of spacecraft in an era of 'better, faster, cheaper'. In the new architecture, the permanent software implements all capabilities needed by any system user, and text tables specify how these capabilities are to be used for each spacecraft. Most changes can now be made rapidly, outside of the traditional software development cycle. The system can be updated to support a new spacecraft through table changes rather than software changes, reducing the implementation, test, and delivery cycle for such a change from three months to three weeks. The mechanical separation of the text table files from the program software, with tables only loaded into memory when that mission is being supported, dramatically reduces the level of regression testing required. The format of each table is a different compromise between ease of human interpretation, efficiency of computer interpretation, and flexibility.

Manning, Evan↗

NASA NTRS2021

Automated Data Accountability for Missions in Mars Rover Data

As the Mars Curiosity Rover transmits data to the JPL Ground Data System (GDS), it frequently observes data loss and corruption, requiring re-transmits from the rover and Ground Data System Analysts (GDSA) to monitor the downlink process. As new missions are launched, the GDSA team redistributes analysts to these new missions, causing shortages in previous missions. The GDSA team can significantly benefit from the automation and optimization of the downlink process of telemetry data. In fact, there is a need for a better understanding of why the data is corrupted, so that the GDSA team can best determine the root cause of the issues in the GDS. This paper presents machine learning and deep learning based approaches to automate and optimize the detection of data loss. We first created a pipeline to automatically accumulate data from the telemetry databases (MAROS, Telemetry Data Storage, and GDS Elastic Search Database) in the downlink process. With our newly created datasets, we perform feature selection to supplement the GDSA understanding of the downlink process and provide supplemental analysis on the importance of different features. We implement various machine learning and deep learning based models, including support vector machines, ensemble methods, and deep neural networks and evaluate their accuracies in identifying whether a downlink process is complete or incomplete. We utilize fast hyperparameter optimization methods that allow our models to quickly be re-trained, allowing them to quickly be tuned and optimized on daily incoming data in real time. This hyperparameter optimization also allows our methods to be quickly integrated into other JPL missions. Our results show that our best-performing machine learning and deep learning based models outperform the existing GDSA detection software by 6 accuracy points and can aid analysts by providing insights into the data accountability problem. Since these various machine learning and deep learning approaches vary significantly in interpretability, we provide a discussion on the tradeoffs between their performance and trustworthiness in helping detect issues in data transmission.

Divsalar, Dariush↗

NASA NTRS2017

Thermal Assessment of Sunlight Impinging on OSIRIS-REx OCAMS PolyCam, OTES, and IMU-Sunshade MLI Blankets in Flight

The NASA Origins, Spectral Interpretation, Resource Identification, Security, Regolith Explorer (OSIRIS-REx) spacecraft was successfully launched into orbit on September 8, 2016. It is traveling to a near-Earth asteroid (101955) Bennu, study it in detail, and bring back a pristine sample to Earth for scientific analyses. At the Outbound Cruise nominal spacecraft attitude, with Sun on +X, sunlight impinges on the OSIRIS-REx camera suite (OCAMS) PolyCam sunshade multilayer insulation (MLI) with microporous black polytetrafluoroethylene (PTFE), a portion of the PolyCam optics support tube (MLI with germanium black Kapton (GBK)), a portion of the OSIRIS-REx Thermal Emission Spectrometer (OTES) sunshade (MLI with GBK), the Inertia Measurement Unit (IMU) sunshade (MLI with GBK), and the OSIRIS-REx Laser Altimeter (OLA) sunshade (MLI with GBK). Sunlight is reflected or scattered by the above MLIs to the other components on the forward (+Z) deck. It illuminates the forward deck. A detailed thermal assessment on the solar impingement has been performed for the Proximity Ops at the asteroid, Touch-and-Go (TAG) sample acquisition, and Return Cruise mission phases.The OSIRIS-REx Outbound Cruise flight temperature telemetry and USM_3_DPC_0_CURRENT flight currenttelemetry data have been analyzed. It is evident that at the nominal Outbound Cruise spacecraft Sun-pointing attitude(i.e., Sun on +X), sunlight impinging on the PolyCam, OTES, IMU-sunshade and OLA-sunshade MLIs is reflected orscattered to the forward deck and components on the forward deck. It illuminates the forward deck. The StowCam imageof Day 265 2016 also provided an evidence. The reflected or scattered sunlight cause warming to the forward deck andcomponents on its +Z side. It may also contribute to degradation of thermal coatings over the mission life. It is a factorthat the OVIRS detector operating temperature exceeds the 105K maximum AFT limit. The OVIRS PrincipalInvestigator indicated that it is not optimum but acceptable for science. With exception of the OVIRS detector, thecorrelated flight system thermal model predictions for the components on the forward deck have adequate margins in theProximity Ops, TAG and Return Cruise phases. The margins are expected to cover the warming caused by the solarimpingement and the contribution to degradation of thermal coatings. The solar impingement is not expected to be athermal risk to the OSIRIS-REx mission. The second SRC Optical Properties characterization will be repeated in theReturn Cruise to provide a good characterization of any changes in optical properties that might have occurred duringthe TAG, or during several years in space. If the SRC battery runs much warmer than that of the first characterization inthe Outbound Cruise, it will be necessary to make some changes to the SRC Release timeline to assure the SRC batterytemperature are within limits. If GBK, instead of microporous black PTFE, were used on the PolyCam sunshade MLI,much more sunlight would have been reflected or scattered to the forward deck and components on its +Z side.Microporous black PTFE should be considered to mitigate the optical and thermal issues of sunlight reflected/scatteredby MLI blankets in future missions.

Choi, Michael K.↗

NASA NTRS2015

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASA's Space Launch System

The engineering development of the new Space Launch System (SLS) launch vehicle requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The characteristics of these spacecraft systems must be matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large and complex system engineering challenge, which is being addressed in part by focusing on the specific subsystems involved in the handling of off-nominal mission and fault tolerance with response management. Using traditional model based system and software engineering design principles from the Unified Modeling Language (UML) and Systems Modeling Language (SysML), the Mission and Fault Management (M&FM) algorithms for the vehicle are crafted and vetted in specialized Integrated Development Teams (IDTs) composed of multiple development disciplines such as Systems Engineering (SE), Flight Software (FSW), Safety and Mission Assurance (S&MA) and the major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GNC), Thrust Vector Control (TVC), and liquid engines. These model based algorithms and their development lifecycle from inception through Flight Software certification are an important focus of this development effort to further insure reliable detection and response to off-nominal vehicle states during all phases of vehicle operation from pre-launch through end of flight. NASA formed a dedicated M&FM team for addressing fault management early in the development lifecycle for the SLS initiative. As part of the development of the M&FM capabilities, this team has developed a dedicated testbed that integrates specific M&FM algorithms, specialized nominal and off-nominal test cases, and vendor-supplied physics-based launch vehicle subsystem models. Additionally, the team has developed processes for implementing and validating these algorithms for concept validation and risk reduction for the SLS program. The flexibility of the Vehicle Management End-to-end Testbed (VMET) enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the developed algorithms utilizing actual subsystem models such as MPS. The intent of VMET is to validate the M&FM algorithms and substantiate them with performance baselines for each of the target vehicle subsystems in an independent platform exterior to the flight software development infrastructure and its related testing entities. In any software development process there is inherent risk in the interpretation and implementation of concepts into software through requirements and test cases into flight software compounded with potential human errors throughout the development lifecycle. Risk reduction is addressed by the M&FM analysis group working with other organizations such as S&MA, Structures and Environments, GNC, Orion, the Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission and Loss of Crew probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and associated detection and responses that can be tested in VMET to ensure that failures can be detected, and confirm that responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - ARINC 653 partitioned OS, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM such as telemetry packing and processing. The baseline plan for use of VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by Flight Software. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure the effectiveness of M&FM algorithms performance in the FSW development and test processes.

Trevino, Luis↗

NASA NTRS2015

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASAs Space Launch System

The engineering development of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS) requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The nominal and off-nominal characteristics of SLS's elements and subsystems must be understood and matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large and complex systems engineering challenge, which is being addressed in part by focusing on the specific subsystems involved in the handling of off-nominal mission and fault tolerance with response management. Using traditional model-based system and software engineering design principles from the Unified Modeling Language (UML) and Systems Modeling Language (SysML), the Mission and Fault Management (M&FM) algorithms for the vehicle are crafted and vetted in Integrated Development Teams (IDTs) composed of multiple development disciplines such as Systems Engineering (SE), Flight Software (FSW), Safety and Mission Assurance (S&MA) and the major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GNC), Thrust Vector Control (TVC), and liquid engines. These model-based algorithms and their development lifecycle from inception through FSW certification are an important focus of SLS's development effort to further ensure reliable detection and response to off-nominal vehicle states during all phases of vehicle operation from pre-launch through end of flight. To test and validate these M&FM algorithms a dedicated test-bed was developed for full Vehicle Management End-to-End Testing (VMET). For addressing fault management (FM) early in the development lifecycle for the SLS program, NASA formed the M&FM team as part of the Integrated Systems Health Management and Automation Branch under the Spacecraft Vehicle Systems Department at the Marshall Space Flight Center (MSFC). To support the development of the FM algorithms, the VMET developed by the M&FM team provides the ability to integrate the algorithms, perform test cases, and integrate vendor-supplied physics-based launch vehicle (LV) subsystem models. Additionally, the team has developed processes for implementing and validating the M&FM algorithms for concept validation and risk reduction. The flexibility of the VMET capabilities enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the developed algorithms utilizing actual subsystem models such as MPS, GNC, and others. One of the principal functions of VMET is to validate the M&FM algorithms and substantiate them with performance baselines for each of the target vehicle subsystems in an independent platform exterior to the flight software test and validation processes. In any software development process there is inherent risk in the interpretation and implementation of concepts from requirements and test cases into flight software compounded with potential human errors throughout the development and regression testing lifecycle. Risk reduction is addressed by the M&FM group but in particular by the Analysis Team working with other organizations such as S&MA, Structures and Environments, GNC, Orion, Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission (LOM) and Loss of Crew (LOC) probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and associated detection and responses to be tested in VMET to ensure reliable failure detection, and confirm responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - the ARINC 6535-partitioned Operating System, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM such as telemetry packing and processing. The baseline plan for use of VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by FSW. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure their effectiveness and performance in the exterior FSW development and test processes. This paper is outlined in a systematic fashion analogous to a lifecycle process flow for engineering development of algorithms into software and testing. Section I describes the NASA SLS M&FM context, presenting the current infrastructure, leading principles, methods, and participants. Section II defines the testing philosophy of the M&FM algorithms as related to VMET followed by section III, which presents the modeling methods of the algorithms to be tested and validated in VMET. Its details are then further presented in section IV followed by Section V presenting integration, test status, and state analysis. Finally, section VI addresses the summary and forward directions followed by the appendices presenting relevant information on terminology and documentation.

Trevino, Luis↗

NASA NTRSDate not supplied

Introduction to the JPSS-2 Advanced Technology Microwave Sounder (ATMS) Government Calibration Data Book (GCDB)

The third Advanced Technology Microwave Sounder (ATMS) is an instrument onboard the Joint Polar Satellite System (JPSS), JPSS-2 (renamed NOAA-21 in orbit) mission. This report is to introduce the JPSS-2 Government Calibration Data Book (J2 GCDB) for ATMS, SN 304. This J2 GCDB document contains key information generated during the calibration testing campaign that is driving parameters for radiometric performance. This document also contains supporting data that augments the calibration results. The values in this document are utilized by ATMS’s calibration packet which is, in turn, an integral component in the interpretation of science data. The calibration data in this report was collected from tests such as shelf-level testing, antenna testing, instrument thermal vacuum (TVAC) testing; satellite TVAC testing; and JPSS-2 post-launch tests. JPSS-2 was launched on November 10, 2022. In the subsequent years, the Government will release an ATMS GCDB for each JPSS mission. We expect that all public users can download these ATMS GCDBs from the NOAA operational Integrated Calibration and Validation System (ICVS) website, see more discussions below. The goal of this GCDB is to demonstrate how to characterize ATMS measurements using JPSS-2 ATMS on-orbit operational data and to provide relevant explanations. This document serves as a primary public domain reference for calibrating operational ATMS Raw Data Records (RDR) science data, as used in the current operational Interface Data Processing Segment (IDPS) system. This same RDR science data is distributed through direct broadcast (DB) to DB users for use in their ground processing systems. This J2 GCDB provides the results of the ATMS system radiometric calibration, the antenna flat reflector emissivity [1], the antenna pattern measurements, the antenna pattern corrected brightness temperature [2], the brightness temperature of the lunar disk [3], Lunar Intrusion (LI) correction algorithm [4], receiver spectral parameters, and mechanical alignment on-orbit pointing results, and the striping effect appeared significantly in S-NPP on-orbit radiance data when the data are compared to the Radiative Transfer Model (RTM) simulation in numerical weather prediction (NWP) system [5]. It also provides the parameters required for conversion of telemetry counts to engineering units, for radiometric calibration, and for antenna beam geo-location. Moreover, it provides JPSS-2 ATMS Spectral Response Functions data, some additional information related to ATMS on-orbit performance, on-orbit lunar intrusion correction parameters and Earth contamination bias, and on how to derive ATMS RDR, antenna Temperature Data Records (TDR), and Sensor Data Records (SDR). Furthermore, an introduction of NOAA operational Integrated Calibration and Validation System (ICVS) website and services is added in this J2 GCDB. This ICVS hosts a long-term monitoring system which allows to visualization and comparison of data from JPSS missions, NOAA legacy Polar Operational Environmental Satellites (POES), and Geostationary Operational Environmental Satellites (GOES). From NOAA Comprehensive Large Array-data Stewardship System (CLASS), the public users can download all JPSS ATMS data products for all JPSS missions.

Microwave Sounder↗