Search NASA⌕ Search

SEARCH · Search NASA

Results for “spacecraft commanding”

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 379 records · Page 21
All sourcesNASA NTRSDOE OSTI
NASA NTRS2016

Center of Mass Estimation for a Spinning Spacecraft Using Doppler Shift of the GPS Carrier Frequency

A sequential filter is presented for estimating the center of mass (CM) of a spinning spacecraft using Doppler shift data from a set of onboard Global Positioning System (GPS) receivers. The advantage of the proposed method is that it is passive and can be run continuously in the background without using commanded thruster firings to excite spacecraft dynamical motion for observability. The NASA Magnetospheric Multiscale (MMS) mission is used as a test case for the CM estimator. The four MMS spacecraft carry star cameras for accurate attitude and spin rate estimation. The angle between the spacecraft nominal spin axis (for MMS this is the geometric body Z-axis) and the major principal axis of inertia is called the coning angle. The transverse components of the estimated rate provide a direct measure of the coning angle. The coning angle has been seen to shift slightly after every orbit and attitude maneuver. This change is attributed to a small asymmetry in the fuel distribution that changes with each burn. This paper shows a correlation between the apparent mass asymmetry deduced from the variations in the coning angle and the CM estimates made using the GPS Doppler data. The consistency between the changes in the coning angle and the CM provides validation of the proposed GPS Doppler method for estimation of the CM on spinning spacecraft.

Estimation↗
NASA NTRS1994

Development of a Solid State Power Switch for the Cassini Spacecraft

The Cassini spacecraft uses a new hybrid device to replace the load switching relays used on previous missions. These hybrid devices provide additional functions such as circuit breaking, controlled voltage turn-on and current limiting features. The current limiting function makes an uninterruptible power system possible. This hybrid, the Solid State Power Switch (SSPS), performs the function of connecting the 192 Cassini loads to the spacecraft power bus in response to commands from the Command and Data subsystem.

Cassini↗
NASA NTRS1990

The Galileo Orbiter - Command and telemetry subsystems on their way to Jupiter

An overview is given of the Galileo command and telemetry subsystems, which exemplify the rigid time-synchronized systems required by TDM (time division multiplexing). The spacecraft clock is examined, along with some of the rationale for the development of the clock structure and timing to give a sense of the design imperatives for rigidly synchronized systems. Additional subjects include the structure of the science and engineering frames, emphasizing the subcommutated structure of the engineering frame and its relationship to the spacecraft clock; ground processing for and basic uses of the telemetry; the various message types used to transmit commands to the spacecraft; and the generation processes for the command message types.

Erickson, James K.↗
NASA NTRS2011

Mission Operations Planning and Scheduling System (MOPSS)

MOPSS is a generic framework that can be configured on the fly to support a wide range of planning and scheduling applications. It is currently used to support seven missions at Goddard Space Flight Center (GSFC) in roles that include science planning, mission planning, and real-time control. Prior to MOPSS, each spacecraft project built its own planning and scheduling capability to plan satellite activities and communications and to create the commands to be uplinked to the spacecraft. This approach required creating a data repository for storing planning and scheduling information, building user interfaces to display data, generating needed scheduling algorithms, and implementing customized external interfaces. Complex scheduling problems that involved reacting to multiple variable situations were analyzed manually. Operators then used the results to add commands to the schedule. Each architecture was unique to specific satellite requirements. MOPSS is an expert system that automates mission operations and frees the flight operations team to concentrate on critical activities. It is easily reconfigured by the flight operations team as the mission evolves. The heart of the system is a custom object-oriented data layer mapped onto an Oracle relational database. The combination of these two technologies allows a user or system engineer to capture any type of scheduling or planning data in the system's generic data storage via a GUI.

Wood, Terri↗
NASA NTRS1993

A packet switched communications system for GRO

This paper describes the packet switched Instrumenters Communication System (ICS) that was developed for the Command Management Facility at GSFC to support the Gamma Ray Observatory (GRO) spacecraft. The GRO ICS serves as a vital science data acquisition link to the GRO scientists to initiate commands for their spacecraft instruments. The system is ready to send and receive messages at any time, 24 hours a day and seven days a week. The system is based on X.25 and the International Standard Organization's (ISO) 7-layer Open Systems Interconnection (OSI) protocol model and has client and server components. The components of the GRO ICS are discussed along with how the Communications Subsystem for Interconnection (CSFI) and Network Control Program Packet Switching Interface (NPSI) software are used in the system.

Husain, Shabu↗
NASA NTRS1988

Docking system for spacecraft

A mechanism is disclosed for the docking of a spacecraft to a space station where a connection for transfer of personnel and equipment is desired. The invention comprises an active docking structure on a spacecraft and a passive docking structure on the station. The passive structure includes a docking ring mounted on a tunnel structure fixed to the space station. The active structure includes a docking ring carried by an actuator-attenuator devices, each attached at one end to the ring and at its other end in the spacecraft payload bay. The devices respond to command signals for moving the docking ring between a stowed position in the spacecraft to a deployed position suitable for engagement with the docking ring. The devices comprise means responsive to signals of sensed loadings to absorb impact energy and retraction means for drawing the coupled spacecraft and station into final docked configuration and moving the tunnel structure to a berthed position in the spacecraft. Latches couple the spacecraft and space station upon contact of the docking rings and latches establish a structural tie between the spacecraft when retracted.

Kahn, Jon B.↗
NASA NTRS1996

A Multithreaded Scheduler for a High-Speed Spacecraft Simulator

The Cassini Spacecraft will soon journey to Saturn to perform a close-up study of the Saturnian system; its rings, moons, magneto-sphere, andf the planet itelf. Sequences of commands will be sent to the spacecraft by ground personnel to control every aspect of the mission. To validate and verify these command sequences, a bit-level, high-speed simulator (HSS) has been developed.

deadlock multiprocessing multithreaded object-orie↗
NASA NTRS1972

Tracking and data relay satellite system configuration and tradeoff study. Volume 5: TDRS spacecraft design, part 1

A dual spin stabilized TDR spacecraft design is presented for low data rate (LDR) and medium data rate (MDR) user spacecraft telecommunication relay service. The relay satellite provides command and data return channels for unmanned users together with duplex voice and data communication channels for manned user spacecraft. TDRS/ground links are in the Ku band. Command links are provided at UHF for LDR users and S band for MDR users. Voice communication channels are provided at UHF/VHF for LDR users and at S band for MDR users. The spacecraft is designed for launch on the Delta 2914 with system deployment planned for 1978. This volume contains a description of the overall TDR spacecraft configuration, a detailed description of the spacecraft subsystems, a reliability analysis, and a product effectiveness plan.

Source record↗
NASA NTRS2009

Maneuver Automation Software

The Maneuver Automation Software (MAS) automates the process of generating commands for maneuvers to keep the spacecraft of the Cassini-Huygens mission on a predetermined prime mission trajectory. Before MAS became available, a team of approximately 10 members had to work about two weeks to design, test, and implement each maneuver in a process that involved running many maneuver-related application programs and then serially handing off data products to other parts of the team. MAS enables a three-member team to design, test, and implement a maneuver in about one-half hour after Navigation has process-tracking data. MAS accepts more than 60 parameters and 22 files as input directly from users. MAS consists of Practical Extraction and Reporting Language (PERL) scripts that link, sequence, and execute the maneuver- related application programs: "Pushing a single button" on a graphical user interface causes MAS to run navigation programs that design a maneuver; programs that create sequences of commands to execute the maneuver on the spacecraft; and a program that generates predictions about maneuver performance and generates reports and other files that enable users to quickly review and verify the maneuver design. MAS can also generate presentation materials, initiate electronic command request forms, and archive all data products for future reference.

Uffelman, Hal↗
NASA NTRS1991

Apollo 14 Mission to Fra Mauro

The 1971 Apollo 14 Mission to Fra Mauro, a lunar highland area, is highlighted in this video. The mission's primary goal was the collection of lunar rocks and soil samples and lunar exploration. The soil and rock sampling was for the geochronological determination of the Moon's evolution and its comparison with that of Earth. A remote data collection station was assembled on the Moon and left for continuous data collection and surface monitoring experiments. The Apollo 14 astronauts were Alan B. Shepard, Edgar D. Mitchell, and Stuart A. Rossa. Astronauts Shepard and Mitchell landed on the Moon (February 5, 1971) and performed the sampling, the EVA, and deployment of the lunar experiments. There is film-footage of the lunar surface, of the command module's approach to both the Moon and the Earth, Moon and Earth spacecraft launching and landing, in-orbit command- and lunar-module docking, and of Mission Control.

Beasley, Brian D.↗
NASA NTRS2005

Avionics System Architecture Tool

Avionics System Architecture Tool (ASAT) is a computer program intended for use during the avionics-system-architecture- design phase of the process of designing a spacecraft for a specific mission. ASAT enables simulation of the dynamics of the command-and-data-handling functions of the spacecraft avionics in the scenarios in which the spacecraft is expected to operate. ASAT is built upon I-Logix Statemate MAGNUM, providing a complement of dynamic system modeling tools, including a graphical user interface (GUI), modeling checking capabilities, and a simulation engine. ASAT augments this with a library of predefined avionics components and additional software to support building and analyzing avionics hardware architectures using these components.

Chau, Savio↗
NASA NTRS2016

On the Maneuvers Operational Response for NASA’s Soil Moisture Active-Passive (SMAP) Mission

The Soil-Moisture Active-Passive (SMAP) spacecraft requires various kinds of in-orbit maneuvers over the course of its three-year mission. The types of maneuvers include pre-planned commissioning maneuvers to reach its science orbit, regularly executed orbit maintenance maneuvers to overcome drag and other nominally occurring phenomena, as well as (the possibility of) collision avoidance maneuvers. The architecture of the spacecraft – in terms of availability of commanding via ground assets, the inherited avionics' ability to sequence and execute commands, and the capability of available subsystems able to carry out maneuvers – was well defined early in the development of the spacecraft and mission, well before the operational plan for responding to maneuver requests was cemented. The systems engineering challenge became: how to accommodate all three types of maneuvers in the confines of this well-defined architecture. This paper will describe how the operations team on SMAP successfully met this challenge. Specifically, it will dive into the three pronged approach that SMAP developed to handle each type of maneuver described above – to meet the timeliness requirements leveraged on the operations team to execute said maneuvers, while continuing to fit within the allotted staffing profile during nominal operations. Defining this paradigm to fit the mission’s architecture meant re-defining the original paradigm, (planned maneuvers being thought of separately than collision avoidance maneuvers), and re-classifying all responses to maneuver requests as variations and permutations of a singular operational response to a maneuver request. This paper will also describe the tools that were created to simplify the human interface and automate as much of the response as was possible. Finally, this paper will describe, at a very high level, some of the problems encountered and lessons learned by the operations team when this process was executed the first four times during the first ninety days of operations. Though the architecture of the operations team's response to maneuver requests will never be repeated exactly, the flexibility that was inserted via redefining the scope of the problem and by redefining the human interfaces should influence future projects' architectures earlier in their development – in the hopes that said influence will save time and money in the future.

Tirona, Joseph↗
NASA NTRS1993

Command/telemetry bus general specification for the NOAA-OPQ polar orbiting environmental satellites and EUMETSAT polar satellite systems

The document is a reference document in the Instrument Interface Description for NOAA-2000 Instruments (GSFC-S-480-53). The requirements reflect the fact that these instruments must be compatible with a number of different polar orbiting satellite vehicles including the NOAA-OPQ satellites and the EUMETSAT METOP satellites. The instrument payload will interface to the spacecraft via several standardized communication busses. The document defines the multiplex data bus conforming to the MIL-STD-1553B protocol for command and telemetry transfer between a spacecraft system and all instruments.

Source record↗
NASA NTRS1996

The Mars surveyor operations project command generation process

The methods employed by the Mars surveyor operations project (MSOP) flight team to accelerate the command generation process are described. The approach adopted was to develop a ground system which could simultaneously support as many as three spacecraft in various phases of flight and two in development. The uplink element of the MSOP is discussed, including the control of the science instruments and the spacecraft bus using real-time commands as well as time-tagged stored sequences. The non-interactive payload command process, the express command process, the coordinated command process and the stored sequence process are described. The automation of these processes resulted in flight operations cost savings while maintaining a minimum of risk.

Brooks, Robert N., Jr.↗
NASA NTRS2004

NASA Tech Briefs, December 2004

opics include: High-Rate Digital Receiver Board; Signal Design for Improved Ranging Among Multiple Transceivers; Automated Analysis, Classification, and Display of Waveforms; Fast-Acquisition/Weak-Signal-Tracking GPS Receiver for HEO; Format for Interchange and Display of 3D Terrain Data; Program Analyzes Radar Altimeter Data; Indoor Navigation using Direction Sensor and Beacons; Software Assists in Responding to Anomalous Conditions; Software for Autonomous Spacecraft Maneuvers; WinPlot; Software for Automated Testing of Mission-Control Displays; Nanocarpets for Trapping Microscopic Particles; Precious-Metal Salt Coatings for Detecting Hydrazines; Amplifying Electrochemical Indicators; Better End-Cap Processing for Oxidation-Resistant Polyimides; Carbon-Fiber Brush Heat Exchangers; Solar-Powered Airplane with Cameras and WLAN; A Resonator for Low-Threshold Frequency Conversion; Masked Proportional Routing; Algorithm Determines Wind Speed and Direction from Venturi-Sensor Data; Feature-Identification and Data-Compression Software; Alternative Attitude Commanding and Control for Precise Spacecraft Landing; Inspecting Friction Stir Welding using Electromagnetic Probes; and Helicity in Supercritical O2/H2 and C7H16/N2 Mixing Layers.

Source record↗
NASA NTRS2014

Using AUTORAD for Cassini File Uplinks: Incorporating Automated Commanding into Mission Operations

As the Cassini spacecraft embarked on the Solstice Mission in October 2010, the flight operations team faced a significant challenge in planning and executing the continuing tour of the Saturnian system. Faced with budget cuts that reduced the science and engineering staff by over a third in size, new and streamlined processes had to be developed to allow the Cassini mission to maintain a high level of science data return with a lower amount of available resources while still minimizing the risk. Automation was deemed an important key in enabling mission operations with reduced workforce and the Cassini flight team has made this goal a priority for the Solstice Mission. The operations team learned about a utility called AUTORAD which would give the flight operations team the ability to program selected command files for radiation up to seven days in advance and help minimize the need for off-shift support that could deplete available staffing during the prime shift hours. This paper will describe how AUTORAD is being utilized by the Cassini flight operations team and the processes that were developed or modified to ensure that proper oversight and verification is maintained in the generation and execution of radiated command files.

Goo, Sherwin↗
NASA NTRS2017

Challenges of Debris-Impact Risk Assessment for Robotic Spacecraft

This paper describes an orbital debris impact risk assessment performed on the command and data subsystem electronics box of QuikSCAT, a functioning spacecraft with approximately 18 years on orbit. Several aspects of the analysis are paid particular attention. First is the modeling of a thermal blanket at a small stand-off distance from the box chassis. The properties of the blanket are such that under some assumptions, it may be treated as an effective bumper shield, and under other assumptions, it may not. The assumptions and their effects on the results of the analysis are explored. Similarly, the configuration of the electronic components inside the chassis are such that several definitions of failure criteria appear plausible. The results of each treatment are presented together and compared with the status of the actual electronics box. The failure predictions vary widely between treatments, and the more conservative assumption sets predict incredulously high probabilities of failure. This is problematic because the conservative assumptions are the ones typically used in analyses for flight projects.

Ratliff, Martin↗