Search NASA⌕ Search

SEARCH · Search NASA

Results for “spacecraft data interfaces”

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 145 records · Page 8
All sourcesNASA NTRSDOE OSTI
NASA NTRS1994

Lessons learned supporting onboard solid-state recorders

With the advance of semiconductor technology, Solid-State Recorders (SSR) have matured and been accepted as primary onboard data storage devices. Their high reliability, simpler interface and control, and high flexibility have made the SSR's a superb choice in today's spacecraft design. While there are many benefits, the use of SSR's may also add significant complexity to ground data systems. For instance, real-time and playback data may be interleaved into the same data stream, making data sequencing and time ordering difficult. Stored data may be played back out of time order, increasing processing load significantly. Data may also be played back after being sorted by Virtual Channels in the SSR, potentially creating bursts in packet rates that exceed the real-time processing capabilities of the ground systems. This paper presents a summary of lessons learned through the efforts in supporting a number of NASA's missions that employ SSR's. It describes various problems encountered through the design process, and their potential impact on ground system performance, resources, and cost. Recommended approaches to minimizing the impact are demonstrated by examples. The discussion leads to the conclusion that the use of SSR's demands an even higher level of cooperation between spacecraft and ground system designers in order to build the most cost effective end-to-end system.

Shi, Jeff↗
NASA NTRS1972

Crew interface specifications preparation for in-flight maintenance and stowage functions

The findings and data products developed during the Phase 2 crew interface specification study are presented. Five new NASA general specifications were prepared: operations location coding system for crew interfaces; loose equipment and stowage management requirements; loose equipment and stowage data base information requirements; spacecraft loose equipment stowage drawing requirements; and inflight stowage management data requirements. Additional data was developed defining inflight maintenance processes and related data concepts for inflight troubleshooting, remove/repair/replace and scheduled maintenance activities. The process of maintenance task and equipment definition during spacecraft design and development was also defined and related data concepts were identified for futher development into formal NASA specifications during future follow-on study phases of the contract.

Parker, F. W.↗
NASA NTRS1982

Space Shuttle and TDRSS telecommunications system interfaces

The telecommunications system interfaces between the spacecraft and the space shuttle, and between the spacecraft and the Tracking and Data Relay Satellite System (TDRSS) are discussed. The payload/shuttle/ground communications network, principle end-to-end link configurations, and requirements for attached and detached payloads are addressed.

Springett, J. C.↗
NASA NTRS1993

The SAMPEX Data Processing Unit

The paper discusses salient features of the SAMPEX Data Processing Unit (DPU), the primary function of which is to collect sensor data to create telemetry packets for transmission to the solid-state recorder located within the Small Explorer Data System. Particular attention is given to the sensor interface electronics, the space command interface, the spacecraft telemetry interface, and the memory mapper of the DPU system; the task scheduling concept; and system reconfiguring. A block diagram of the DPU system is included.

Mabry, D. J.↗
NASA NTRS1993

A MOS for all seasons

From a systems perspective, this paper examines the challenges of a single system to support multiple JPL space exploration missions and the need for unitary responsibility for the system. The focus is a Mission Operations System (MOS), which is effectively a mission management organization with direct authority over data system operations, command sequencing, flight operations control, data management, trajectory determination, telemetry and data acquisition, and spacecraft analysis. Stratagems for training and the approach to processes, procedures, and interfaces to facilitate the transition from the present situation to a truly multimission operational environment are developed. The outcome is a paradigm for a MOS that is achievable, that can effectively support multiple projects, and that can take advantage of technological changes without perturbing the entire system.

Bryant, Larry↗
NASA NTRS1994

The role of mission operations in spacecraft integration and test

The participation of mission operations personnel in the spacecraft integration and test process offers significant benefits to spacecraft programs in terms of test efficiency, staffing and training efficiency, test completeness, and subsequent cost containment. Operations personnel who have had real-time contact experience and have been responsible for the assessment of on orbit spacecraft operations bring a unique view of spacecraft operations to pre-launch spacecraft test activities. Because of the unique view of the spacecraft/ground interface that experienced operations personnel have, they can propose optimum test approaches and optimum test data analysis techniques. Additionally, the testing that is typically required to validate operations methodologies can be integrated into spacecraft performance testing scenarios.

Harvey, Raymond J.↗
NASA NTRS1994

Dynamic gravity Probe-B spacecraft due to gravity jitter induced cryogenic helium disturbances in rotating dewar

The dynamical behavior of fluids, in particular the effect of surface tension on partially-filled rotating fluids (cryogenic liquid helium and helium vapor) in a full scale Gravity Probe-B Spacecraft propellant dewar tank imposed by various frequencies of gravity jitters have been investigated. The study shows that slosh waves excited inside the spacecraft propellant tank are characterized by the lowest frequency of the waves initiated, frequencies of the gravity jitters imposed on the propellant system, the levels of background gravity environment, and dewar rotating speeds. Conditions for suppression and amplification of the slosh waves are discussed. It also shows that fluid stress distribution exerted on the walls of the rotating dewar are closely related to the characteristics of slosh waves excited on the liquid-vapor interface in the rotating dewar tank. This can provide a set of data leading toward the control of spacecraft imbalance caused by the uneven fluid stress distribution from slosh waves.

Hung, R. J.↗
NASA NTRS1994

Dynamic Characteristics of the Partially Filled Rotating Dewar of the Gravity Probe-B Spacecraft

The dynamical behavior of fluids, in particular the effect of surface tension on partially-filled rotating fluids (cryogenic liquid helium and helium vapor) in a full scale Gravity Probe-B Spacecraft propellant dewar tank imposed by various frequencies of gravity jitters have been investigated. The study of the liquid-vapor interface oscillations due to various frequencies of gravity jitter under different dewar rotating speeds and different levels of background gravity have been numerically simulated. Results disclose the time sequence evolution for the excitation of large amplitude oscillation waves at the liquid-vapor interface. The study shows that slosh waves excited inside the spacecraft propellant tank are characterized by the lowest frequency of the waves initiated, frequencies of the gravity jitters imposed on the propellant system, the levels of background gravity environment, and dewar rotating speeds. Conditions for suppression and amplification of the slosh waves are discussed. It also shows that fluid stress distribution exerted on the walls of the rotating dewar are closely related to the characteristics of slosh waves excited on the liquid-vapor interface in the rotating dewar tank. This can provide a set of data leading toward the control of spacecraft imbalance caused by the uneven fluid stress distribution from slosh waves.

Hung, R. J.↗
NASA NTRS1988

A multiprocessing architecture for real-time monitoring

A multitasking architecture for performing real-time monitoring and analysis using knowledge-based problem solving techniques is described. To handle asynchronous inputs and perform in real time, the system consists of three or more distributed processes which run concurrently and communicate via a message passing scheme. The Data Management Process acquires, compresses, and routes the incoming sensor data to other processes. The Inference Process consists of a high performance inference engine that performs a real-time analysis on the state and health of the physical system. The I/O Process receives sensor data from the Data Management Process and status messages and recommendations from the Inference Process, updates its graphical displays in real time, and acts as the interface to the console operator. The distributed architecture has been interfaced to an actual spacecraft (NASA's Hubble Space Telescope) and is able to process the incoming telemetry in real-time (i.e., several hundred data changes per second). The system is being used in two locations for different purposes: (1) in Sunnyville, California at the Space Telescope Test Control Center it is used in the preflight testing of the vehicle; and (2) in Greenbelt, Maryland at NASA/Goddard it is being used on an experimental basis in flight operations for health and safety monitoring.

Schmidt, James L.↗
NASA NTRS2013

Science Opportunity Analyzer (SOA) Version 8

SOA allows scientists to plan spacecraft observations. It facilitates the identification of geometrically interesting times in a spacecraft s orbit that a user can use to plan observations or instrument-driven spacecraft maneuvers. These observations can then be visualized multiple ways in both two- and three-dimensional views. When observations have been optimized within a spacecraft's flight rules, the resulting plans can be output for use by other JPL uplink tools. Now in its eighth major version, SOA improves on these capabilities in a modern and integrated fashion. SOA consists of five major functions: Opportunity Search, Visualization, Observation Design, Constraint Checking, and Data Output. Opportunity Search is a GUI-driven interface to existing search engines that can be used to identify times when a spacecraft is in a specific geometrical relationship with other bodies in the solar system. This function can be used for advanced mission planning as well as for making last-minute adjustments to mission sequences in response to trajectory modifications. Visualization is a key aspect of SOA. The user can view observation opportunities in either a 3D representation or as a 2D map projection. Observation Design allows the user to orient the spacecraft and visualize the projection of the instrument field of view for that orientation using the same views as Opportunity Search. Constraint Checking is provided to validate various geometrical and physical aspects of an observation design. The user has the ability to easily create custom rules or to use official project-generated flight rules. This capability may also allow scientists to easily assess the cost to science if flight rule changes occur. Data Output allows the user to compute ancillary data related to an observation or to a given position of the spacecraft along its trajectory. The data can be saved as a tab-delimited text file or viewed as a graph. SOA combines science planning functionality unique to both JPL and the sponsoring spacecraft. SOA is able to ingest JPL SPICE Kernels that are used to drive the tool and its computations. A Percy search engine is then included that identifies interesting time periods for the user to build observations. When observations are then built, flight-like orientation algorithms replicate spacecraft dynamics to closely simulate the flight spacecraft s dynamics. SOA v8 represents large steps forward from SOA v7 in terms of quality, reliability, maintainability, efficiency, and user experience. A tailored agile development environment has been built around SOA that provides automated unit testing, continuous build and integration, a consolidated Web-based code and documentation storage environment, modern Java enhancements, and a focus on usability

Witoff, Robert J.↗
NASA NTRS2006

Secure Display of Space-Exploration Images

Java EDR Display Interface (JEDI) is software for either local display or secure Internet distribution, to authorized clients, of image data acquired from cameras aboard spacecraft engaged in exploration of remote planets. ( EDR signifies experimental data record, which, in effect, signifies image data.) Processed at NASA s Multimission Image Processing Laboratory (MIPL), the data can be from either near-realtime processing streams or stored files. JEDI uses the Java Advanced Imaging application program interface, plus input/output packages that are parts of the Video Image Communication and Retrieval software of the MIPL, to display images. JEDI can be run as either a standalone application program or within a Web browser as a servlet with an applet front end. In either operating mode, JEDI communicates using the HTTP(s) protocol(s). In the Web-browser case, the user must provide a password to gain access. For each user and/or image data type, there is a configuration file, called a "personality file," containing parameters that control the layout of the displays and the information to be included in them. Once JEDI has accepted the user s password, it processes the requested EDR (provided that user is authorized to receive the specific EDR) to create a display according to the user s personality file.

Cheng, Cecilia↗
NASA NTRS2014

Manchester Coding Option for SpaceWire: Providing Choices for System Level Design

This paper proposes an optional coding scheme for SpaceWire in lieu of the current Data Strobe scheme for three reasons. First reason is to provide a straightforward method for electrical isolation of the interface; secondly to provide ability to reduce the mass and bend radius of the SpaceWire cable; and thirdly to provide a means for a common physical layer over which multiple spacecraft onboard data link protocols could operate for a wide range of data rates. The intent is to accomplish these goals without significant change to existing SpaceWire design investments. The ability to optionally use Manchester coding in place of the current Data Strobe coding provides the ability to DC balanced the signal transitions unlike the SpaceWire Data Strobe coding; and therefore the ability to isolate the electrical interface without concern. Additionally, because the Manchester code has the clock and data encoded on the same signal, the number of wires of the existing SpaceWire cable could be optionally reduced by 50. This reduction could be an important consideration for many users of SpaceWire as indicated by the already existing effort underway by the SpaceWire working group to reduce the cable mass and bend radius by elimination of shields. However, reducing the signal count by half would provide even greater gains. It is proposed to restrict the data rate for the optional Manchester coding to a fixed data rate of 10 Megabits per second (Mbps) in order to make the necessary changes simple and still able to run in current radiation tolerant Field Programmable Gate Arrays (FPGAs). Even with this constraint, 10 Mbps will meet many applications where SpaceWire is used. These include command and control applications and many instruments applications with have moderate data rate. For most NASA flight implementations, SpaceWire designs are in rad-tolerant FPGAs, and the desire to preserve the heritage design investment is important for cost and risk considerations. The Manchester coding option can be accommodated in existing designs with only changes to the FPGA.

Electrical Isolation↗
NASA NTRS2006

Flight Operations Analysis Tool

Flight Operations Analysis Tool (FLOAT) is a computer program that partly automates the process of assessing the benefits of planning spacecraft missions to incorporate various combinations of launch vehicles and payloads. Designed primarily for use by an experienced systems engineer, FLOAT makes it possible to perform a preliminary analysis of trade-offs and costs of a proposed mission in days, whereas previously, such an analysis typically lasted months. FLOAT surveys a variety of prior missions by querying data from authoritative NASA sources pertaining to 20 to 30 mission and interface parameters that define space missions. FLOAT provides automated, flexible means for comparing the parameters to determine compatibility or the lack thereof among payloads, spacecraft, and launch vehicles, and for displaying the results of such comparisons. Sparseness, typical of the data available for analysis, does not confound this software. FLOAT effects an iterative process that identifies modifications of parameters that could render compatible an otherwise incompatible mission set.

Easter, Robert↗
NASA NTRS2020

Shield to Pin Coupling of Lightning-Like Transients on Payload Umbilical Cables on a Launch Pad

In this paper we describe in-situ testing of a long payload umbilical, on a launch site, injected with “lightning- like” transients and describe resulting pin-to-pin voltages. Injections and voltage measurements near the ground support equipment room, as well as at a location near the payload junction box, are made. The umbilical cables tested include an outer over-braid and the inner conductor coupling is examined for open circuit, short-circuit and various loads representative of spacecraft input impedances. This testing is important because the Kennedy Space Center (KSC) where the lightning occurrence is the highest in the United States, is the primary launch site for Launch Services Program spacecraft customers. Lightning planning is essential but developing a lightning plan is often overlooked or not adequately analyzed leaving the spacecraft vulnerable to time delays or even damage when lightning occurs. At other popular launch sites like Vandenberg Air Force Base (VAFB) where lightning occurs less often, although at the same or greater intensity when it does occur, lightning planning is often completely ignored by the spacecraft. The two major questions to be addressed in the lightning plan are what retesting should be done to establish a “goodness” level and what is the trigger criteria for this testing? The spacecraft will typically use a standard spacecraft check-out procedure to address the necessary retesting, but determining the trigger criteria is often an issue. For instance, a spacecraft needs to understand what their immunity is to a certain lightning magnitude and location. Determining the amount of current that can be coupled onto a spacecraft umbilical can be calculated by using worst case assumptions or measured with current probes and current measurement devices. Spacecraft can also determine what pin-to-pin voltages they are sensitive to, however pin-to-pin voltage measurements are not typically taken during the strike due to the invasive nature of this measurement. In this paper, we present detailed data on the shield to pin voltage transfer functions to provide insight to the spacecraft developers for lightning retest criteria planning. The results from this unique testing opportunity provide essential details on specific coupling mechanisms affecting spacecraft hardware that interfaces with the ground support equipment. This missing link between cable shield currents and payload susceptibility voltages has been methodically tested and representative data presented.

Trout, Dawn↗
NASA NTRS1987

The Giotto electron plasma experiment

The RPA-Copernic experiment aboard Giotto is described. The experiment is designed to measure the three-dimensional distributions of electrons between 10 eV and 30 keV (by the RPA-1 EESA spectrometer) and the composition and distribution, close to the comet, of thermal positive ions in the mass range 10-213 amu (by the RPA-2 PICCA electrostatic mass analyzer). Three microprocessors interface RPA-1 EESA with RPA-2 PICCA and with the spacecraft and perform extensive onboard data processing. The experiment was operated successfully aboard the spacecraft in September 1985 during the encounter of Giotto with the comet Halley. The results provided by the EESA-1 indicate that the solar wind interaction with the comet Halley forms a well-defined bow shock with features quite different from the features of the comet Giacobini-Zinner bow shock; the data also showed a presence of accelerated keV electrons at the cometary bow shock, upstream and in the transition region.

Reme, H.↗
NASA NTRS1996

Combining Acceleration and Displacement Dependent Modal Frequency Responses Using an MSC/NASTRAN DMAP Alter

Solving for dynamic responses of free-free launch vehicle/spacecraft systems acted upon by buffeting winds is commonly performed throughout the aerospace industry. Due to the unpredictable nature of this wind loading event, these problems are typically solved using frequency response random analysis techniques. To generate dynamic responses for spacecraft with statically-indeterminate interfaces, spacecraft contractors prefer to develop models which have response transformation matrices developed for mode acceleration data recovery. This method transforms spacecraft boundary accelerations and displacements into internal responses. Unfortunately, standard MSC/NASTRAN modal frequency response solution sequences cannot be used to combine acceleration- and displacement-dependent responses required for spacecraft mode acceleration data recovery. External user-written computer codes can be used with MSC/NASTRAN output to perform such combinations, but these methods can be labor and computer resource intensive. Taking advantage of the analytical and computer resource efficiencies inherent within MS C/NASTRAN, a DMAP Alter has been developed to combine acceleration- and displacement-dependent modal frequency responses for performing spacecraft mode acceleration data recovery. The Alter has been used successfully to efficiently solve a common aerospace buffeting wind analysis.

Barnett, Alan R.↗
NASA NTRS2001

Flight Computer Design for the Space Technology 5 (ST-5) Mission

As part of NASA's New Millennium Program, the Space Technology 5 mission will validate a variety of technologies for nano-satellite and constellation mission applications. Included are: a miniaturized and low power X-band transponder, a constellation communication and navigation transceiver, a cold gas micro-thruster, two different variable emittance (thermal) controllers, flex cables for solar array power collection, autonomous groundbased constellation management tools, and a new CMOS ultra low-power, radiation-tolerant, +0.5 volt logic technology. The ST-5 focus is on small and low-power. A single-processor, multi-function flight computer will implement direct digital and analog interfaces to all of the other spacecraft subsystems and components. There will not be a distributed data system that uses a standardized serial bus such as MIL-STD-1553 or MIL-STD-1773. The flight software running on the single processor will be responsible for all real-time processing associated with: guidance, navigation and control, command and data handling (C&DH) including uplink/downlink, power switching and battery charge management, science data analysis and storage, intra-constellation communications, and housekeeping data collection and logging. As a nanosatellite trail-blazer for future constellations of up to 100 separate space vehicles, ST-5 will demonstrate a compact (single board), low power (5.5 watts) solution to the data acquisition, control, communications, processing and storage requirements that have traditionally required an entire network of separate circuit boards and/or avionics boxes. In addition to the New Millennium technologies, other major spacecraft subsystems include the power system electronics, a lithium-ion battery, triple-junction solar cell arrays, a science-grade magnetometer, a miniature spinning sun sensor, and a propulsion system.

Speer, David↗