Search NASA⌕ Search

SEARCH · Search NASA

Results for “Data 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.

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

At least 919 records · Page 51
All sourcesNASA NTRSDOE OSTI
NASA NTRS1989

Orbital maneuvering vehicle teleoperation and video data compression

The Orbital Maneuvering Vehicle (OMV) and concepts of teleoperation and video data compression as applied to OMV design and operation are described. The OMV provides spacecraft delivery, retrieval, reboost, deboost and viewing services, with ground-control or Space Station operation, through autonomous navigation and pilot controlled maneuvers. Communications systems are comprised of S-band RF command, telemetry, and compressed video data links through the TDRSS and GSTDN networks. The control console video monitors display a monochrome image at an update rate of five frames per second. Depending upon the mode of operation selected by the pilot, the video resolution is either 255 x 244 pixels, or 510 x 244 pixels. Since practically all video image redundancy is removed by the compression process, the video reconstruction is particularly sensitive to data transmission bit errors. Concatenated Reed-Solomon and convolution coding are used with helical data interleaving for error detection and correction, and an error-containment process minimizes the propagation of error effects throughout the video image. Video sub-frame replacement is used, in the case of a non-correctable error or error burst, to minimize the visual impact to the pilot.

Jones, Steve↗
NASA NTRS1990

Application of CCSDS packet telemetry recommendations by JPL

The Consultative Committee for Space Data Systems (CCSDS) has adopted three Recommendations dealing with telemetry for conventional missions: Packet Telemetry, Telemetry Channel Coding and Time Code Formats. The currently flying JPL spacecraft were designed prior to the adoption of these Recommendations. Future JPL missions will be compatible, as will the Deep Space Network and Space Flight Operations Center. This paper discusses ways in which application of the Recommendations causes or allows functions to be done differently from previous JPL projects, including the impact on timing and on telemetry adaptability.

Moyd, K. I.↗
NASA NTRS1981

Space tracking and data systems; Proceedings of the Symposium, Arlington, VA, June 16-18, 1981

The AIAA/NASA Symposium on Space Tracking and Data Systems, held in Pentagon City, Virginia, on June 16-18, 1981, had the purpose of reviewing international activities in space tracking and data systems for civil use in the 1980-2000 time frame. Participants included 225 representatives from industrial and government organizations in eight nations. The nations represented include the United States, France, Germany, India, Japan, Norway, Spain, and Sweden. The major functions of the systems described at the Symposium are related to the initial downlink of telemetry and spacecraft status data, attendant tracking activities, and uplink of spacecraft commands; communication between the associated acquisition sites and central processing and control stations; formulation and implementation of commands that control the spacecraft and its payload; and processing of spacecraft data needed to make command decisions. Attention is given to an overview of current activities and plans, and supporting developments, taking into account the time from 1980 to 1990. New developments are also considered.

Grey, J.↗
NASA NTRS1978

Propulsion/flight control integration technology (PROFIT) software system definition

The Propulsion Flight Control Integration Technology (PROFIT) program is designed to develop a flying testbed dedicated to controls research. The control software for PROFIT is defined. Maximum flexibility, needed for long term use of the flight facility, is achieved through a modular design. The Host program, processes inputs from the telemetry uplink, aircraft central computer, cockpit computer control and plant sensors to form an input data base for use by the control algorithms. The control algorithms, programmed as application modules, process the input data to generate an output data base. The Host program formats the data for output to the telemetry downlink, the cockpit computer control, and the control effectors. Two applications modules are defined - the bill of materials F-100 engine control and the bill of materials F-15 inlet control.

Carlin, C. M.↗
NASA NTRS2013

Multi-User Space Link Extension (SLE) System

The Multi-User Space (MUS) Link Extension system, a software and data system, provides Space Link Extension (SLE) users with three space data transfer services in timely, complete, and offline modes as applicable according to standards defined by the Consultative Committee for Space Data Systems (CCSDS). MUS radically reduces the schedule, cost, and risk of implementing a new SLE user system, minimizes operating costs with a lights-out approach to SLE, and is designed to require no sustaining engineering expense during its lifetime unless changes in the CCSDS SLE standards, combined with new provider implementations, force changes. No software modification to MUS needs to be made to support a new mission. Any systems engineer with Linux experience can begin testing SLE user service instances with MUS starting from a personal computer (PC) within five days. For flight operators, MUS provides a familiar-looking Web page for entering SLE configuration data received from SLE. Operators can also use the Web page to back up a space mission's entire set of up to approximately 500 SLE service instances in less than five seconds, or to restore or transfer from another system the same amount of data from a MUS backup file in about the same amount of time. Missions operate each MUS SLE service instance independently by sending it MUS directives, which are legible, plain ASCII strings. MUS directives are usually (but not necessarily) sent through a TCP-IP (Transmission Control Protocol Internet Protocol) socket from a MOC (Mission Operations Center) or POCC (Payload Operations Control Center) system, under scripted control, during "lights-out" spacecraft operation. MUS permits the flight operations team to configure independently each of its data interfaces; not only commands and telemetry, but also MUS status messages to the MOC. Interfaces can use single- or multiple-client TCP/IP server sockets, TCP/IP client sockets, temporary disk files, the system log, or standard in, standard out, or standard error as applicable. By defining MUS templates in ASCII, the flight operations team can include any MUS system variable in telemetry or command headers or footers, and/or in status messages. Data fields can be arranged within messages in different sequences, according to the mission s needs. The only constraints imposed are on the format of MUS directive strings, and some bare minimum logical requirements that must be met in order for MUS to read the mission control center's spacecraft command inputs. The MUS system imposes no limits or constraints on the numbers and combinations of missions and SLE service instances that it will support simultaneously. At any time, flight operators may add, change, delete, bind, connect, or disconnect.

Perkins, Toby↗
NASA NTRSDate not supplied

Artemis I Liftoff Measurements Issues and Corrections

The SLS rocket was instrumented to collect liftoff environment data during Artemis I launch. The instruments were microphones and pressure transducers. Most data were acceptable for analysis, but required corrections for port resonance, mean signal drift, data system delays, and data spikes. The data were all transmitted via telemetry and in this process some of the measurements experienced unexpectedly long gaps in the data stream. A time validated reconstruction algorithm failed when encountering the long gaps and required use of data from a simpler reconstruction process, with manually inserted data delay corrections. This paper discusses the issues and the corrections that were necessary for the launch data to determine the true physics of the acoustics occurring during launch.

environments↗
NASA NTRSDate not supplied

Artemis I Liftoff Measurements Issues and Corrections

The SLS rocket was instrumented to collect liftoff environment data during Artemis I launch. The instruments were microphones and pressure transducers. Most data were acceptable for analysis, but required corrections for port resonance, mean signal drift, data system delays, and data spikes. The data were all transmitted via telemetry and in this process some of the measurements experienced unexpectedly long gaps in the data stream. A time validated reconstruction algorithm failed when encountering the long gaps and required use of data from a simpler reconstruction process, with manually inserted data delay corrections. This paper discusses the issues and the corrections that were necessary for the launch data to determine the true physics of the acoustics occurring during launch.

environments↗
NASA NTRS2000

GPS Sounding Rocket Development at NASA with Simultaneous Multi-Payload Tracking Application

An inverse differential GPS system has been developed for Sounding Rocket use which includes the flight unit and a ground station capable of extracting GPS data from sounding rocket telemetry, performing a real time differential solution and graphically displaying the rocket's path relative to a predicted trajectory plot. Accuracy has been proven to within less than 10 meters. Postprocessing has increased the precision to within 10 - 20 centimeters. The system has been successfully flown several times and delivered to the Sounding Program Office for routine field use. In addition to providing position, velocity and time GPS data has been used on sounding rockets for vehicle performance analysis, effecting a one hundred fold improvement in data time tagging, and steering an optical tracking device to intercept payloads launched from over the horizon. Precise velocity separation information and timing has been provided to multiple payload systems. Future plans include its use for Range Safety and enabling of interferometric techniques. The technology and software developed also has potential application to small satellite navigation and formation flying.

Bull, Barton↗
NASA NTRS2019

Cognitive Communications for NASA Space Systems

The growing complexity of spacecraft constellations, communication relay offerings, and mission architectures drives the need for the development of autonomous communication systems. NASA has traditionally launched single spacecraft missions that are served by the Space Communication and Navigation (SCaN) program. Operations on SCaN networks are typically scheduled weeks in advance, and often each asset serves a single user spacecraft at a time. Recent movement towards swarm missions could make the current approach unsustainable. Additionally, the integration of commercial communication service providers will substantially increase the data transfer options available to new missions. NASA science missions have found benefit in launching swarms of spacecraft, allowing coordinated simultaneous observations from different perspectives. Inter-spacecraft communication (mesh networking) is an enabler for this architecture, as are CubeSats that allow cost-effective provisioning of distributed mission assets. As more complex swarm missions launch, one challenge is coordinating communication within the swarm and choosing the appropriate mechanism for telemetry, tracking, control, and data services to and from Earth. Cognitive communications research conducted by SCaN aims to mitigate the increasing communication complexity for mission users by increasing the autonomy of links, networks, and service scheduling. By considering automation techniques including recent advances in artificial intelligence and machine learning, cognitive algorithms and related approaches enable increased mission science return, improved resource utilization for service provider networks, and resiliency in unpredictable or unplanned environments. The Cognitive Communications Project at the NASA Glenn Research Center develops applications of data-driven, non-deterministic methods to improve the autonomy of space communication. The project emphasizes development of decentralized space networks with artificial intelligence agents optimizing communication link throughput, data routing, and system-wide asset management. This paper discusses the objectives, approaches, and opportunities of the research to address growing needs of the space communications community.

Chelmins, David↗
NASA NTRS1988

Mission telemetry system monitor: A real-time knowledge-based system

The Galileo Mission Telemetry System (MTS) has a cluster of computer subsystems configured as a star network. The MTS handles the real-time processing of spacecraft telemetry and ground monitor data. Large volumes of status and fault messages are generated as a result of changes in the system environment. These messages are triggered by the conditions that exist on any one particular subsystem or device. The order of message generation is in time sequence and does not always correlate to the function sequence of active processes. A significant number of messages provide context with varying degrees of uncertainty. As such, highly skilled telemetry controllers are required to regularly go through high volumes of messages generated by the MTS to identify, diagnose, and isolate faults. A knowledge-based system prototype is being developed to monitor the Galileo Mission Telemetry System performance. The system design approach features temporal reasoning, uncertainty management, and intelligent graphic user interfaces.

Mouneimne, Samih A.↗
NASA NTRS1982

A flight test maneuver autopilot for a highly manueverable aircraft

A flight test maneuver autopilot (FTMAP) is currently being flown to increase the quality and quantity of the data obtained in the flight testing of the highly maneuverable aircraft technology (HiMAT) remotely piloted research vehicle (RPRV). The FTMAP resides in a ground-based digital computer and was designed to perform certain prescribed maneuvers precisely, while maintaining critical flight parameters within close tolerances. The FTMAP operates as a non-flight-critical outer loop controller and augments the vehicle primary flight control system. The inputs to the FTMAP consist of telemetry-downlinked aircraft sensor data. During FTMAP operation, the FTMAP computer replaces normal pilot inputs to the aircraft stick and throttle positions. The FTMAP maneuvers include straight-and-level flight, level accelerations and decelerations, pushover pullups, and windup turns. The pushover pullups can be executed holding throttle or Mach number fixed. The windup turns can be commanded by either normal acceleration or angle of attack. The operational procedures, control mode configuration, and initial simulation results are discussed.

Roncoli, R. B.↗
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 NTRSDate not supplied

James Webb Space Telescope Navigation Optimization Challenges

The James Webb Space Telescope (JWST) is a NASA flagship mission launched on December 25, 2021. The early orbit phase was highlighted by three midcourse correction burns that were performed to maneuver the vehicle into a libration orbit at the second Sun-Earth-Moon (SEM) libration point (L2). During the coast to L2, the vehicle’s primary observatory and sunshield were deployed. Once the tennis-court-sized sunshield was unfurled and tensioned into place, the large area exposed to solar radiation pressure (SRP) dictated that the SRP force model would need to account for the vehicle’s geometry, reflective properties, and orientation relative to the Sun. Following the insertion of JWST into its L2 libration orbit on January 24, 2022, the commissioning phase for the vehicle’s observatory commenced along with the first cycle of routine station-keeping maneuvers. The NASA Goddard Space Flight Center’s Flight Dynamics Facility (FDF) provides navigation services for the JWST mission. The FDF serves as the prime or backup navigation operations center for more than 30 active missions spanning a wide array of flight regimes performing orbit determination, maneuver planning, trajectory optimization, and tracking data evaluation. Definitive orbit determination for JWST is performed by the FDF using an Extended Kalman Filter (EKF) to estimate the vehicle’s trajectory and reflective properties using Deep Space Network (DSN) TRK-2-34 tracking data and spacecraft attitude telemetry. For the purposes of orbit prediction and station-keeping maneuver targeting, the sensitivity of the SRP force to the vehicle’s orientation requires that predictive attitude information must be incorporated to generate accurate orbit predictions and maneuver plans. Predictive attitude plans are provided to the FDF by the JWST Spacecraft Operations Center (SOC). Short-term (28 day) orbit predictions are propagated using a Short Range Attitude Plan (SRAP) to model the vehicle’s future attitude states for up to a week. SRAP attitude data is highly reliable, as it reflects finalized planned attitude states that the vehicle will be commanded to attain during the ensuing week. A Long Range Attitude Plan (LRAP) can be implemented to model predicted attitude states beyond one week, but these predictions are tentative and subject to revision due to changes in science operations plans. Instead, a conservative approach of applying a Sun-Pointing Neutral (SPN) attitude configuration is utilized for long-term (2 year) orbit predictions where reliable planned attitude data is not available. SPN attitude mode aligns the net SRP force along the JWST-to-Sun vector where it becomes independent of the vehicle’s angle of rotation about this vector, defined as the Sun yaw. Given the dynamic instability of the libration orbit, station-keeping thrust must be applied in either the sunward or anti-sunward direction to balance the resulting orbit. The attitude constraints of the vehicle also impose limits on the available pointing directions for station-keeping thrusters. The thrusters cannot be aligned with the optimal pointing direction for sunward maneuvers, rendering sunward maneuvers to be significantly less fuel efficient than anti-sunward maneuvers. Consequently, station-keeping maneuvers must be targeted to balance the orbit while ensuring that the next maneuver will also be performed in the anti-sunward direction to optimize propellant usage. When targeting a station-keeping maneuver, the attitude and SRP modeling configuration which is applied to the predicted post-maneuver trajectory will dictate the direction of the subsequent station-keeping maneuver, assuming nominal propulsion system performance. If the predicted post-maneuver attitude states result in an SRP model which under-predicts the cumulative SRP impact on the post-maneuver orbit, a targeted anti-sunward maneuver will be larger than necessary and the next maneuver will need to be executed sunward in order to compensate. In contrast, an anti-sunward maneuver which is targeted using an SRP model which over-predicts the cumulative SRP impact will achieve station-keeping while ensuring that the next maneuver will likewise be performed anti-sunward. For this reason, station-keeping maneuvers are targeted while applying the SPN attitude mode, as this mode entails the largest possible SRP area cross-section and therefore a larger modeled cumulative SRP impact. This paper documents the NASA Goddard Space Flight Center’s FDF support for JWST on-orbit operations and the analysis projects undertaken utilizing the experiences and data accumulated throughout the first full year of routine science operations. The results of these analysis efforts have been used to implement improvements to orbit prediction accuracy and maneuver efficiency which have the potential to prolong the lifespan of JWST to continue to conduct ground-breaking infrared astronomy for decades to come.

Flight Dynamics↗
NASA NTRS2018

Status of and Scientific Results from the ISIS-I Topside Digital Ionogram Data Enhancement Project

Selected original analog telemetry tapes from three of the topside-sounder satellites of the International Satellites for Ionospheric Studies (ISIS) program, namely Alouette 2, ISIS I, and ISIS II, were used in an earlier project to produce more than million digital topside ionograms; the resulting digital topside ionograms from ISIS II were used to produce morethan 86,000 globally-distributed vertical topside ionospheric electron density profiles Ne(h)that cover a time span of more than a solar cycle. These Ne(h) were produced using the TOPIST auto-scaling software. Before attempting to automatically process Alouette-2 orISIS-I ionograms a data-enhancement project was initiated so as to increase the auto processing success rate. These enhancements were mainly to correct problems that often occurred during the analog-to-digital conversion of the original telemetry tapes. Here we present the status of, and results from, this ongoing enhancement effort.

topside ionosphere↗
NASA NTRS2006

A Multi-mission Event-Driven Component-Based System for Support of Flight Software Development, ATLO, and Operations first used by the Mars Science Laboratory (MSL) Project

This paper details an architectural description of the Mission Data Processing and Control System (MPCS), an event-driven, multi-mission ground data processing components providing uplink, downlink, and data management capabilities which will support the Mars Science Laboratory (MSL) project as its first target mission. MPCS is developed based on a set of small reusable components, implemented in Java, each designed with a specific function and well-defined interfaces. An industry standard messaging bus is used to transfer information among system components. Components generate standard messages which are used to capture system information, as well as triggers to support the event-driven architecture of the system. Event-driven systems are highly desirable for processing high-rate telemetry (science and engineering) data, and for supporting automation for many mission operations processes.

Mission Data Processing and Control System (MPCS)↗
NASA NTRS1994

The Advanced Orbiting Systems Testbed Program: Results to date

The Consultative Committee for Space Data Systems (CCSDS) Recommendations for Packet Telemetry (PT) and Advanced Orbiting Systems (AOS) propose standard solutions to data handling problems common to many types of space missions. The Recommendations address only space/ground and space/space data handling systems. Goddard Space Flight Center's (GSFC's) AOS Testbed (AOST) Program was initiated to better understand the Recommendations and their impact on real-world systems, and to examine the extended domain of ground/ground data handling systems. The results and products of the Program will reduce the uncertainties associated with the development of operational space and ground systems that implement the Recommendations.

Otranto, John F.↗
NASA NTRS2005

"XMM/RXTE Observations of GX 339-4"

In March 2003, we performed two simultaneous XMM/RXTE observations of the black hole candidate GX 339-4. Our goal is to compare these data to our prior simultaneous RXTE/ASCA observations (Nowak, Wilms & Dove, 2002). These observations were carried out in timing mode, as opposed to burst mode, and are more complex to analyze than we expected. Specifically, the data suffered from a number of telemetry dropouts (in fact, the standard archive processing failed on these data, and more than a year passed from the time of the observations before the data was delivered to us). Furthermore, the core of the EPIC PSF suffers slightly from pileup and gain shifts. We continue to work on this data, however, and anticipate publishing it within the next academic year. Here we highlight our ongoing work and outline our plans for publication.

Nowak, M. A.↗