Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Spacecraft 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 271 records · Page 15
All sourcesNASA NTRSDOE OSTI
NASA NTRS1993

Results from the US/Russian Meteor-3/Total Ozone Mapping Spectrometer

The development of Meteor-3/TOMS (Total Ozone Mapping Spectrometer) was a joint project of the United States and Russia to fly a U.S. ozone measuring instrument (TOMS) onboard a Russian spacecraft (Meteor-3) and rocket (Cyclone), launched from Plesetsk, Russia. The Meteor-3/TOMS (M3TOMS) was launched into a 1202-km-high, near-polar orbit on 15 Aug. 1991, where it can obtain complete global coverage for most of each year. Both the U.S. and Russian sides have successfully received and processed data into ozone amounts from 25 Aug. 1991 to 1 Jun. 1992, and expect to continue for the life of the instrument and spacecraft. The successful development of the instrument hardware, spacecraft interface, data memory, telemetry systems, and software are described. Descriptions are given of the U.S. and Russian ground stations for receiving M3TOMS data. In addition, the data reduction software was independently developed by the U.S. and by the Russians, and is shown to agree to better than the precision of the measurements.

Herman, Jay R.↗
NASA NTRS1994

Mapping Between Distinct Reed-Solomon Codes

One-to-one mapping between two Reed-Solomon (RS) codes devised to enable decoder designed for one of codes to operate on other one also. Codes in question must have same N and K parameters (defined below) but otherwise be two distinct RS codes. Mapping intended to enable same ground-based decoder to decode telemetry signals from two spacecraft in two different RS codes of (N,K) = (255,223). Also useful in purely terrestrial data communications and in optical and magnetic recording and playback of digitized audio and video signals. Implemented in interface circuitry and/or software to enable communication between coding systems of different manufacturers using different RS codes within same (N,K) family.

Perlman, Marvin↗
NASA NTRS1993

Hubble Space Telescope Pointing Control System design improvement study

As part of the NASA Controls/Structures Integration Program, a study was undertaken to determine if improvements to the performance of the Hubble Space Telescope Pointing Control System could be obtained when advanced control system design techniques were applied using simulation models and telemetry data from the spacecraft. The study was managed through the Marshall Space Flight Center. Four universities and one aerospace company developed controller designs and tested their performance. This paper summarizes the goals and provides an overview of the study.

Bukley, Angelia P.↗
NASA NTRS1995

Clouds and the Earth's Radiant Energy System (CERES) algorithm theoretical basis document: Geolocation, calibration, and ERBE-like analyses (subsystems 1-3) - volume 2

The theoretical bases for the Release 1 algorithms that will be used to process satellite data for investigation of the Clouds and Earth's Radiant Energy System (CERES) are described. The architecture for software implementation of the methodologies is outlined. Volume 2 details the techniques used to geolocate and calibrate the CERES scanning radiometer measurements of shortwave and longwave radiance to invert the radiances to top-of-the-atmosphere (TOA) and surface fluxes following the Earth Radiation Budget Experiment (ERBE) approach, and to average the fluxes over various time and spatial scales to produce an ERBE-like product. Spacecraft ephemeris and sensor telemetry are used with calibration coefficients to produce a chronologically ordered data product called bidirectional scan (BDS) radiances. A spatially organized instrument Earth scan product is developed for the cloud-processing subsystem. The ERBE-like inversion subsystem converts BDS radiances to unfiltered instantaneous TOA and surface fluxes. The TOA fluxes are determined by using established ERBE techniques. Hourly TOA fluxes are computed from the instantaneous values by using ERBE methods. Hourly surface fluxes are estimated from TOA fluxes by using simple parameterizations based on recent research. The averaging process produces daily, monthly-hourly, and monthly means of TOA and surface fluxes at various scales. This product provides a continuation of the ERBE record.

Wielicki, B. A.↗
NASA NTRS2003

XML: James Webb Space Telescope Database Issues, Lessons, and Status

This paper will present the current concept using extensible Markup Language (XML) as the underlying structure for the James Webb Space Telescope (JWST) database. The purpose of using XML is to provide a JWST database, independent of any portion of the ground system, yet still compatible with the various systems using a variety of different structures. The testing of the JWST Flight Software (FSW) started in 2002, yet the launch is scheduled for 2011 with a planned 5-year mission and a 5-year follow on option. The initial database and ground system elements, including the commands, telemetry, and ground system tools will be used for 19 years, plus post mission activities. During the Integration and Test (I&T) phases of the JWST development, 24 distinct laboratories, each geographically dispersed, will have local database tools with an XML database. Each of these laboratories database tools will be used for the exporting and importing of data both locally and to a central database system, inputting data to the database certification process, and providing various reports. A centralized certified database repository will be maintained by the Space Telescope Science Institute (STScI), in Baltimore, Maryland, USA. One of the challenges for the database is to be flexible enough to allow for the upgrade, addition or changing of individual items without effecting the entire ground system. Also, using XML should allow for the altering of the import and export formats needed by the various elements, tracking the verification/validation of each database item, allow many organizations to provide database inputs, and the merging of the many existing database processes into one central database structure throughout the JWST program. Many National Aeronautics and Space Administration (NASA) projects have attempted to take advantage of open source and commercial technology. Often this causes a greater reliance on the use of Commercial-Off-The-Shelf (COTS), which is often limiting. In our review of the database requirements and the COTS software available, only very expensive COTS software will meet 90% of requirements. Even with the high projected initial cost of COTS, the development and support for custom code over the 19-year mission period was forecasted to be higher than the total licensing costs. A group did look at reusing existing database tools and formats. If the JWST database was already in a mature state, the reuse made sense, but with the database still needing to handing the addition of different types of command and telemetry structures, defining new spacecraft systems, accept input and export to systems which has not been defined yet, XML provided the flexibility desired. It remains to be determined whether the XML database will reduce the over all cost for the JWST mission.

Detter, Ryan↗
NASA NTRS2005

Coupled Receiver/Decoders for Low-Rate Turbo Codes

been proposed for receiving weak single- channel phase-modulated radio signals bearing low-rate-turbo-coded binary data. Originally intended for use in receiving telemetry signals from distant spacecraft, the proposed receiver/ decoders may also provide enhanced reception in mobile radiotelephone systems. A radio signal of the type to which the proposal applies comprises a residual carrier signal and a phase-modulated data signal. The residual carrier signal is needed as a phase reference for demodulation as a prerequisite to decoding. Low-rate turbo codes afford high coding gains and thereby enable the extraction of data from arriving radio signals that might otherwise be too weak. In the case of a conventional receiver, if the signal-to-noise ratio (specifically, the symbol energy to one-sided noise power spectral density) of the arriving signal is below approximately 0 dB, then there may not be enough energy per symbol to enable the receiver to recover properly the carrier phase. One could solve the problem at the transmitter by diverting some power from the data signal to the residual carrier. A better solution . a coupled receiver/decoder according to the proposal . could reduce the needed amount of residual carrier power. In all that follows, it is to be understood that all processing would be digital and the incoming signals to be processed would be, more precisely, outputs of analog-to-digital converters that preprocess the residual carrier and data signals at a rate of multiple samples per symbol. The upper part of the figure depicts a conventional receiving system, in which the receiver and decoder are uncoupled, and which is also called a non-data-aided system because output data from the decoder are not used in the receiver to aid in recovering the carrier phase. The receiver tracks the carrier phase from the residual carrier signal and uses the carrier phase to wipe phase noise off the data signal. The receiver typically includes a phase-locked loop (PLL) or Costas loop that requires no delay or perhaps a single sample delay. The lower part of the figure depicts a basic coupled receiver/decoder . a data-aided system that would implement an iterative receiving/decoding process. The receiver would include a PLL or a Wiener filter that, to the extent possible, would track the residual carrier signal, wipe phase noise off the data signal, then send the result to the turbo decoder. Recovery of timing could be effected by, for example, a digital transition tracking loop (DTTL) or other, similar loop. The first iteration of turbo decoding would yield soft data symbols, which would be sent back to the receiver for use in softly wiping off the data signal in an effort to recover the residual carrier signal. The wiped signal would contain a relatively large carrier-phase component that could be tracked by use of a second Wiener filter.

Hamkins, Jon↗
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 NTRS2012

Compact Autonomous Hemispheric Vision System

Solar System Exploration camera implementations to date have involved either single cameras with wide field-of-view (FOV) and consequently coarser spatial resolution, cameras on a movable mast, or single cameras necessitating rotation of the host vehicle to afford visibility outside a relatively narrow FOV. These cameras require detailed commanding from the ground or separate onboard computers to operate properly, and are incapable of making decisions based on image content that control pointing and downlink strategy. For color, a filter wheel having selectable positions was often added, which added moving parts, size, mass, power, and reduced reliability. A system was developed based on a general-purpose miniature visible-light camera using advanced CMOS (complementary metal oxide semiconductor) imager technology. The baseline camera has a 92 FOV and six cameras are arranged in an angled-up carousel fashion, with FOV overlaps such that the system has a 360 FOV (azimuth). A seventh camera, also with a FOV of 92 , is installed normal to the plane of the other 6 cameras giving the system a > 90 FOV in elevation and completing the hemispheric vision system. A central unit houses the common electronics box (CEB) controlling the system (power conversion, data processing, memory, and control software). Stereo is achieved by adding a second system on a baseline, and color is achieved by stacking two more systems (for a total of three, each system equipped with its own filter.) Two connectors on the bottom of the CEB provide a connection to a carrier (rover, spacecraft, balloon, etc.) for telemetry, commands, and power. This system has no moving parts. The system's onboard software (SW) supports autonomous operations such as pattern recognition and tracking.

Pingree, Paula J.↗
NASA NTRS2014

Spot: A Programming Language for Verified Flight Software

The C programming language is widely used for programming space flight software and other safety-critical real time systems. C, however, is far from ideal for this purpose: as is well known, it is both low-level and unsafe. This paper describes Spot, a language derived from C for programming space flight systems. Spot aims to maintain compatibility with existing C code while improving the language and supporting verification with the SPIN model checker. The major features of Spot include actor-based concurrency, distributed state with message passing and transactional updates, and annotations for testing and verification. Spot also supports domain-specific annotations for managing spacecraft state, e.g., communicating telemetry information to the ground. We describe the motivation and design rationale for Spot, give an overview of the design, provide examples of Spot's capabilities, and discuss the current status of the implementation.

validation↗
NASA NTRS2016

Arcus: The X-Ray Grating Spectrometer Explorer

Arcus will be proposed to the NASA Explorer program as a free-flying satellite mission that will enable high-resolution soft X-ray spectroscopy (8-50 Angstroms) with unprecedented sensitivity-effective areas of greater than 500 sq cm and spectral resolution greater than 2500. The Arcus key science goals are (1) to determine how baryons cycle in and out of galaxies by measuring the effects of structure formation imprinted upon the hot gas that is predicted to lie in extended halos around galaxies, groups, and clusters, (2) to determine how black holes influence their surroundings by tracing the propagation of out-flowing mass, energy and momentum from the vicinity of the black hole out to large scales and (3) to understand how accretion forms and evolves stars and circumstellar disks by observing hot infalling and outflowing gas in these systems. Arcus relies upon grazing incidence silicon pore X-ray optics with the same 12m focal length (achieved using an extendable optical bench) that will be used for the ESA Athena mission. The focused X-rays from these optics will then be diffracted by high-efficiency off-plane reflection gratings that have already been demonstrated on sub-orbital rocked flights, imaging the results with flight-proven CCD detectors and electronics. The power and telemetry requirements on the spacecraft are modest. The majority of mission operations will not be complex, as most observations will be long (~100 ksec), uninterrupted, and pre-planned, although there will be limited capabilities to observe targets of opportunity, such as tidal disruption events or supernovae with a 3-5 day turnaround. After the end of prime science, we plan to allow guest observations to maximize the science return of Arcus to the community.

Instrumentation↗
NASA NTRS1994

Fault Protection Design for the Command and Data Subsystem on the Cassini Spacecraft

The Command and Data Subsystem (CDS) on Cassini is responsible for uplink command processing, spacecraft intercommunications and control, and downlink telemetry formatting. The 10.7 year mission life, 160 minute round-trip light time, and extended periods of operation without continuous ground communications drive the CDS design in directions of redundancy, autonomy, and fault protection to accomodate the mission objectives.

Cassini↗
NASA NTRS2019

MarCO: flight results from the first interplanetary CubeSat mission

On November 26, 2018, the MarCO spacecraft successfully flew by Mars while relaying entry-descent-and-landing telemetry for the InSight vehicle. Both spacecraft performed beyond expectations and were able to provide a realtime link for the so-called ”seven minutes of terror”. In addition, once InSight safely landed, it transmitted its first image of the Martian surface through MarCO. Over the following weeks, images of Mars and Phobos, performance and health information of the spacecraft, and historical data were all downlinked.

Klesh, Andrew T.↗
NASA NTRS1972

Tracking and data system support for the Mariner Mars 1971 mission. Prelaunch phase through first trajectory correction maneuver, volume 1

The DSN command system provided the capability to enter commands in a computer at the deep space stations for transmission to the spacecraft. The high-rate telemetry system operated at 16,200 bits/sec. This system will permit return to DSS 14 of full-resolution television pictures from the spacecraft tape recorder, plus the other science experiment data, during the two playback periods of each Goldstone pass planned for each corresponding orbit. Other features included 4800 bits/sec modem high-speed data lines from all deep space stations to Space Flight Operations Facility (SFOF) and the Goddard Space Flight Center, as well as 50,000 bits/sec wideband data lines from DSS 14 to the SFOF, thus providing the capability for data flow of two 16,200 bits/sec high-rate telemetry data streams in real time. The TDS performed prelaunch training and testing and provided support for the Mariner Mars 1971/Mission Operations System training and testing. The facilities of the ETR, DSS 71, and stations of the MSFN provided flight support coverage at launch and during the near-earth phase. The DSSs 12, 14, 41, and 51 of the DSN provided the deep space phase support from 30 May 1971 through 4 June 1971.

Laeser, R. P.↗
NASA NTRS1994

Simplifying operations with an uplink/downlink integration toolkit

The Operations Engineering Lab (OEL) at JPL has developed a simple, generic toolkit to integrate the uplink/downlink processes, (often called closing the loop), in JPL's Multimission Ground Data System. This toolkit provides capabilities for integrating telemetry verification points with predicted spacecraft commands and ground events in the Mission Sequence Of Events (SOE) document. In the JPL ground data system, the uplink processing functions and the downlink processing functions are separate subsystems that are not well integrated because of the nature of planetary missions with large one-way light times for spacecraft-to-ground communication. Our new closed-loop monitoring tool allows an analyst or mission controller to view and save uplink commands and ground events with their corresponding downlinked telemetry values regardless of the delay in downlink telemetry and without requiring real-time intervention by the user. An SOE document is a time-ordered list of all the planned ground and spacecraft events, including all commands, sequence loads, ground events, significant mission activities, spacecraft status, and resource allocations. The SOE document is generated by expansion and integration of spacecraft sequence files, ground station allocations, navigation files, and other ground event files. This SOE generation process has been automated within the OEL and includes a graphical, object-oriented SOE editor and real-time viewing tool running under X/Motif. The SOE toolkit was used as the framework for the integrated implementation. The SOE is used by flight engineers to coordinate their operations tasks, serving as a predict data set in ground operations and mission control. The closed-loop SOE toolkit allows simple, automated integration of predicted uplink events with correlated telemetry points in a single SOE document for on-screen viewing and archiving. It automatically interfaces with existing real-time or non real-time sources of information, to display actual values from the telemetry data stream. This toolkit was designed to greatly simplify the user's ability to access and view telemetry data, and also provide a means to view this data in the context of the commands and ground events that are used to interpret it. A closed-loop system can prove especially useful in small missions with limited resources requiring automated monitoring tools. This paper will discuss the toolkit implementation, including design trade-offs and future plans for enhancing the automated capabilities.

Murphy, Susan C.↗
NASA NTRS1993

Magellan spacecraft and memory state tracking: Lessons learned, future thoughts

Numerous studies have been dedicated to improving the two main elements of Spacecraft Mission Operations: Command and Telemetry. As a result, not much attention has been given to other tasks that can become tedious, repetitive, and error prone. One such task is Spacecraft and Memory State Tracking, the process by which the status of critical spacecraft components, parameters, and the contents of on-board memory are managed on the ground to maintain knowledge of spacecraft and memory states for future testing, anomaly investigation, and on-board memory reconstruction. The task of Spacecraft and Memory State Tracking has traditionally been a manual task allocated to Mission Operations Procedures. During nominal Mission Operations this job is tedious and error prone. Because the task is not complex and can be accomplished manually, the worth of a sophisticated software tool is often questioned. However, in the event of an anomaly which alters spacecraft components autonomously or a memory anomaly such as a corrupt memory or flight software error, an accurate ground image that can be reconstructed quickly is a priceless commodity. This study explores the process of Spacecraft and Memory State Tracking used by the Magellan Spacecraft Team highlighting its strengths as well as identifying lessons learned during the primary and extended missions, two memory anomalies, and other hardships encountered due to incomplete knowledge of spacecraft states. Ideas for future state tracking tools that require minimal user interaction and are integrated into the Ground Data System will also be discussed.

Bucher, Allen W.↗
NASA NTRS2002

REACH: Real-Time Data Awareness in Multi-Spacecraft Missions

Missions have been proposed that will use multiple spacecraft to perform scientific or commercial tasks. Indeed, in the commercial world, some spacecraft constellations already exist. Aside from the technical challenges of constructing and flying these missions, there is also the financial challenge presented by the tradition model of the flight operations team (FOT) when it is applied to a constellation mission. Proposed constellation missions range in size from three spacecraft to more than 50. If the current ratio of three-to-five FOT personnel per spacecraft is maintained, the size of the FOT becomes cost prohibitive. The Advanced Architectures and Automation Branch at the Goddard Space Flight Center (GSFC Code 588) saw the potential to reduce the cost of these missions by creating new user interfaces to the ground system health-and-safety data. The goal is to enable a smaller FOT to remain aware and responsive to the increased amount of ground system information in a multi-spacecraft environment. Rather than abandon the tried and true, these interfaces were developed to run alongside existing ground system software to provide additional support to the FOT. These new user interfaces have been combined in a tool called REACH. REACH-the Real-time Evaluation and Analysis of Consolidated Health-is a software product that uses advanced visualization techniques to make spacecraft anomalies easy to spot, no matter how many spacecraft are in the constellation. REACH reads a real-time stream of data from the ground system and displays it to the FOT such that anomalies are easy to pick out and investigate. Data visualization has been used in ground system operations for many years. To provide a unique visualization tool, we developed a unique source of data to visualize: the REACH Health Model Engine. The Health Model Engine is rule-based software that receives real-time telemetry information and outputs "health" information related to the subsystems and spacecraft that the telemetry belong to. The Health Engine can run out-of-the-box or can be tailored with a scripting language. Out of the box, it uses limit violations to determine the health of subsystems and spacecraft; when tailored, it determines health using equations combining the values and limits of any telemetry in the spacecraft. The REACH visualizations then "roll up" the information from the Health Engine into high level, summary displays. These summary visualizations can be "zoomed" into for increasing levels of detail. Currently REACH is installed in the Small Explorer (SMEX) lab at GSFC, and is monitoring three of their five spacecraft. We are scheduled to install REACH in the Mid-sized Explorer (MIDEX) lab, which will allow us to monitor up to six more spacecraft. The process of installing and using our "research" software in an operational environment has provided many insights into which parts of REACH are a step forward and which of our ideas are missteps. Our paper explores both the new concepts in spacecraft health-and-safety visualization, the difficulties of such systems in the operational environment, and the cost and safety issues of multi-spacecraft missions.

Maks, Lori↗
NASA NTRS1974

Computers and prospects for an on-board spacecraft electronic equipment

Conversion of spaceborne telemetry and transceiving data with digital computers is discussed. The ways computers may allow selection of the most informative of the total number of measurements are discussed along with development of compatible transceiver equipment.

Andreyanov, V. V.↗