Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “spacecraft uplink commands”

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 19 records
All sourcesNASA NTRSDOE OSTI
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 NTRS2007

Automatic Command Sequence Generation

Automatic Sequence Generator (Autogen) Version 3.0 software automatically generates command sequences for the Mars Reconnaissance Orbiter (MRO) and several other JPL spacecraft operated by the multi-mission support team. Autogen uses standard JPL sequencing tools like APGEN, ASP, SEQGEN, and the DOM database to automate the generation of uplink command products, Spacecraft Command Message Format (SCMF) files, and the corresponding ground command products, DSN Keywords Files (DKF). Autogen supports all the major multi-mission mission phases including the cruise, aerobraking, mapping/science, and relay mission phases. Autogen is a Perl script, which functions within the mission operations UNIX environment. It consists of two parts: a set of model files and the autogen Perl script. Autogen encodes the behaviors of the system into a model and encodes algorithms for context sensitive customizations of the modeled behaviors. The model includes knowledge of different mission phases and how the resultant command products must differ for these phases. The executable software portion of Autogen, automates the setup and use of APGEN for constructing a spacecraft activity sequence file (SASF). The setup includes file retrieval through the DOM (Distributed Object Manager), an object database used to store project files. This step retrieves all the needed input files for generating the command products. Depending on the mission phase, Autogen also uses the ASP (Automated Sequence Processor) and SEQGEN to generate the command product sent to the spacecraft. Autogen also provides the means for customizing sequences through the use of configuration files. By automating the majority of the sequencing generation process, Autogen eliminates many sequence generation errors commonly introduced by manually constructing spacecraft command sequences. Through the layering of commands into the sequence by a series of scheduling algorithms, users are able to rapidly and reliably construct the desired uplink command products. With the aid of Autogen, sequences may be produced in a matter of hours instead of weeks, with a significant reduction in the number of people on the sequence team. As a result, the uplink product generation process is significantly streamlined and mission risk is significantly reduced. Autogen is used for operations of MRO, Mars Global Surveyor (MGS), Mars Exploration Rover (MER), Mars Odyssey, and will be used for operations of Phoenix. Autogen Version 3.0 is the operational version of Autogen including the MRO adaptation for the cruise mission phase, and was also used for development of the aerobraking and mapping mission phases for MRO.

Fisher, Forest↗
NASA NTRS1985

Spacecraft commanding for unmanned planetary missions - The uplink process

A general description of the command generation process for unmanned planetary missions is presented. Emphasis is given to those mission characteristics which significantly affect the cost of the uplink process including: the level of mission activity; mission strategies; permissible risk; and spacecraft design. Pertinent examples of the command generation procedures used in the Voyager, Mariner, and Viking programs are given in order to illustrate the different stages of the uplink process.

Linick, T. D.↗
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 NTRS2008

Uplink Array Concept Demonstration with the EPOXI Spacecraft

Uplink array technology is currently being developed for NASA's Deep Space Network (DSN) to provide greater range and data throughput for future NASA missions, including manned missions to Mars and exploratory missions to the outer planets, the Kuiper belt, and beyond. Here we describe a novel technique for generating the frequency predicts that are used to compensate for relative Doppler, derived from interpolated earth position and spacecraft ephemerides. The method described here guarantees velocity and range estimates that are consistent with each other, hence one can always be recovered from the other. Experimental results have recently proven that these frequency predicts are accurate enough to maintain the phase of a three element array at the EPOXI spacecraft for three hours. Previous methods derive frequency predicts directly from interpolated relative velocities. However, these velocities were found to be inconsistent with the corresponding spacecraft range, meaning that range could not always be recovered accurately from the velocity predicts, and vice versa. Nevertheless, velocity-based predicts are also capable of maintaining uplink array phase calibration for extended periods, as demonstrated with the EPOXI spacecraft, however with these predicts important range and phase information may be lost. A comparison of the steering-vector method with velocity-based techniques for generating precise frequency predicts specifically for uplink array applications is provided in the following sections.

spacecraft uplink commands↗
NASA NTRS2018

Multiple Uplinks Per Antenna (MUPA) Signal Acquisition Schemes

The Deep Space Network (DSN) currently makes use of the technique of Multiple Spacecraft per Antenna (MSPA) where a single antenna is used to track multiple spacecraft downlinks within its beam, such as in the case of multiple spacecraft orbiting Mars at 8.4 GHz (X-band). It is desired to extend this technique to the uplink where a single station is used to send a signal to multiple spacecraft in order to make more efficient use of ground resources. This would be applicable to numerous smallsat constellations being considered for future missions or to future spacecraft at Venus, Mars, or more distant destinations that are all within the half-power beamwidth of a single 34-m diameter antenna. In one scheme, each spacecraft’s command sequences would be time multiplexed onto a single uplink frequency. Each spacecraft would lock onto the uplink signal and would accept only commands intended for it via special identifier codes. Each spacecraft would also emit a downlink signal to the ground that is coherent with the uplink signal but would have its own allocated frequency channel and identifier information. A couple of key challenges associated with using this technique need to be addressed. Because of the single uplink frequency, coherent turnaround for two-way Doppler and ranging would not conform to established ratios, thus the radios employed by the spacecraft would need to be capable of variable turnaround ratios. In addition, because of the different orbits or spacecraft trajectories, the relative Doppler shifts and rates can be large with respect to the common uplink signal whose frequency would lie at the centroid of the frequencies of the expected received signals of the constellation. This would be problematic with standard analog spacecraft radios whose acquisition bandwidths are relatively small (~1.7 kHz) relative to the large frequency offsets (~100 kHz) expected using the single frequency uplink technique. With the advent of software defined radios (SDRs), signal frequency search algorithms can be utilized within the flight software and/or programmable hardware (e.g., FPGAs) that can easily acquire and track signals with large frequency offsets and varying dynamics. Such techniques could include FFT search algorithms, step-and-sweep search algorithms, or onboard frequency steering making use of trajectory vectors uplinked to each member spacecraft. Other challenges include mitigation of potential interference between received signals. We have identified several software defined radios that are in different stages of development and whose key parameters have been tabulated. We have examined each radio’s capabilities with respect to acquiring and tracking signals with large frequency offsets. Such analyses made use of previous studies supplemented with specially designed tests using both simulation tools and/or existing testbeds. We have compared signal acquisition times computed from provided algorithms along with measured values derived from tests using existing hardware and simulation tools for the purpose of conducting tradeoff studies between the various radio designs and software/firmware programming approaches.

Abraham, Douglas S.↗
NASA NTRS1990

A new environment for multiple spacecraft power subsystem mission operations

The engineering analysis subsystem environment (EASE) is being developed to enable fewer controllers to monitor and control power and other spacecraft engineering subsystems. The EASE prototype has been developed to support simultaneous real-time monitoring of several spacecraft engineering subsystems. It is being designed to assist with offline analysis of telemetry data to determine trends, and to help formulate uplink commands to the spacecraft. An early version of the EASE prototype has been installed in the JPL Space Flight Operations Facility for online testing. The EASE prototype is installed in the Galileo Mission Support Area. The underlying concept, development, and testing of the EASE prototype and how it will aid in the ground operations of spacecraft power subsystems are discussed.

Bahrami, K. A.↗
NASA NTRS2016

Human Flight to Lunar and Beyond - Re-Learning Operations Paradigms

For the first time since the Apollo era, NASA is planning on sending astronauts on flights beyond Low-Earth Orbit (LEO). The Human Space Flight (HSF) program started with a successful initial flight in Earth orbit, in December 2014. The program will continue with two Exploration Missions (EM) to Lunar orbit: EM-1 will be unmanned and EM-2, carrying astronauts, will follow. NASA established a multi-center team to address the communications, and related navigation, needs. This paper will focus on the lessons learned in the team, planning for the missions' parts that are beyond Earth orbit. Many of these lessons had to be re-learned, as the HSF program after operated for many years in Earth orbit. Fortunately, the experience base from tracking robotic missions in deep space by the Deep Space Network (DSN) and close interaction with the HSF community to understand the unique needs (e.g. 2-way voice) resulted in a ConOps that leverages of both the deep space robotic and the Human LEO experiences. Several examples will be used to highlight the unique operational needs for HSF missions beyond Earth Orbit, including: - Navigation. At LEO, HSF missions can rely on Global Positioning System (GPS) devices for orbit determination. For Lunar-and-beyond HSF missions, techniques such as precision 2-way and 3-way Doppler and ranging, Delta-Difference-of-range, and eventually on-board navigation will be used. - Impact of latency - the delay associated with Round-Trip-Light-Time (RTLT). Imagine trying to have a 2-way discussion (audio or video) with an astronaut, with a 2-3 sec delay inserted (for Lunar distances) or 20 minutes delay (for Mars distances). - Balanced communications link. For robotic missions, there has been a heavy emphasis on the downlink data rates, bringing back science data from the instruments on-board the spacecraft. Uplink data rates were of secondary importance, used to send commands to the spacecraft. The ratio of downlink-to-uplink data rates was often 10:1 or more. For HSF, rates for uplink and downlink, at least for high-quality video, need to be similar.

Kenny, Ted↗
NASA NTRS2006

Lessons Learned from Daily Uplink Operations during the Deep Impact Mission

The daily preparation of uplink products (commands and files) for Deep Impact was as problematic as the final encounter images were spectacular. The operations team was faced with many challenges during the six-month mission to comet Tempel One of the biggest difficulties was that the Deep Impact Flyby and Impactor vehicles necessitated a high volume of uplink products while also utilizing a new uplink file transfer capability. The Jet Propulsion Laboratory (JPL) Multi-Mission Ground Systems and Services (MGSS) Mission Planning and Sequence Team (MPST) had the responsibility of preparing the uplink products for use on the two spacecraft. These responsibilities included processing nearly 15,000 flight products, modeling the states of the spacecraft during all activities for subsystem review, and ensuring that the proper commands and files were uplinked to the spacecraft. To guarantee this transpired and the health and safety of the two spacecraft were not jeopardized several new ground scripts and procedures were developed while the Deep Impact Flyby and Impactor spacecraft were en route to their encounter with Tempel-1. These scripts underwent several adaptations throughout the entire mission up until three days before the separation of the Flyby and Impactor vehicles. The problems presented by Deep Impact's daily operations and the development of scripts and procedures to ease those challenges resulted in several valuable lessons learned. These lessons are now being integrated into the design of current and future MGSS missions at JPL.

uplink↗
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 NTRS1981

An application of computer aided requirements analysis to a real time deep space system

The entire procedure of incorporating the requirements and goals of a space flight project into integrated, time ordered sequences of spacecraft commands, is called the uplink process. The Uplink Process Control Task (UPCT) was created to examine the uplink process and determine ways to improve it. The Problem Statement Language/Problem Statement Analyzer (PSL/PSA) designed to assist the designer/analyst/engineer in the preparation of specifications of an information system is used as a supporting tool to aid in the analysis. Attention is given to a definition of the uplink process, the definition of PSL/PSA, the construction of a PSA database, the value of analysis to the study of the uplink process, and the PSL/PSA lessons learned.

Farny, A. M.↗
NASA NTRS1986

An expert system prototype for aiding in the development of software functional requirements for NASA Goddard's command management system: A case study and lessons learned

At NASA Goddard, the role of the command management system (CMS) is to transform general requests for spacecraft opeerations into detailed operational plans to be uplinked to the spacecraft. The CMS is part of the NASA Data System which entails the downlink of science and engineering data from NASA near-earth satellites to the user, and the uplink of command and control data to the spacecraft. Presently, it takes one to three years, with meetings once or twice a week, to determine functional requirements for CMS software design. As an alternative approach to the present technique of developing CMS software functional requirements, an expert system prototype was developed to aid in this function. Specifically, the knowledge base was formulated through interactions with domain experts, and was then linked to an existing expert system application generator called 'Knowledge Engineering System (Version 1.3).' Knowledge base development focused on four major steps: (1) develop the problem-oriented attribute hierachy; (2) determine the knowledge management approach; (3) encode the knowledge base; and (4) validate, test, certify, and evaluate the knowledge base and the expert system prototype as a whole. Backcasting was accomplished for validating and testing the expert system prototype. Knowledge refinement, evaluation, and implementation procedures of the expert system prototype were then transacted.

Liebowitz, Jay↗
NASA NTRS1983

The Deep Space Network: A Radio Communications Instrument for Deep Space Exploration

The primary purpose of the Deep Space Network (DSN) is to serve as a communications instrument for deep space exploration, providing communications between the spacecraft and the ground facilities. The uplink communications channel provides instructions or commands to the spacecraft. The downlink communications channel provides command verification and spacecraft engineering and science instrument payload data.

Renzetti, N. A.↗
NASA NTRS2016

Extended Bright Bodies - Flight and Ground Software Challenges on the Cassini Mission at Saturn

Extended bright bodies in the Saturn environment such as Saturn's rings, the planet itself, and Saturn's satellites near the Cassini spacecraft may interfere with the star tracker's ability to find stars. These interferences can create faulty spacecraft attitude knowledge, which would decrease the pointing accuracy or even trip a fault protection response on board the spacecraft. The effects of the extended bright body interference were observed in December of 2000 when Cassini flew by Jupiter. Based on this flight experience and expected star tracker behavior at Saturn, the Cassini AACS operations team defined flight rules to suspend the star tracker during predicted interference windows. The flight rules are also implemented in the existing ground software called Kinematic Predictor Tool to create star identification suspend commands to be uplinked to the spacecraft for future predicted interferences. This paper discusses the details of how extended bright bodies impact Cassini's acquisition of attitude knowledge, how the observed data helped the ground engineers in developing flight rules, and how automated methods are used in the flight and ground software to ensure the spacecraft is continuously operated within these flight rules. This paper also discusses how these established procedures will continue to be used to overcome new bright body challenges that Cassini will encounter during its dips inside the rings of Saturn for its final orbits of a remarkable 20-year mission at Saturn.

Sung, Tina S.↗
NASA NTRS2016

Initial Satellite Formation Flight Results from the Magnetospheric Multiscale Mission

This paper will describe the results that have been obtained to date concerning MMS formation flying. The MMS spacecraft spin at a rate of 3.1 RPM, with spin axis roughly aligned with Ecliptic North. Several booms are used to deploy instruments: two 5 m magnetometer booms in the spin plane, two rigid booms of length 12.5 m along the positive and negative spin axes, and four flexible wire booms of length 60 m in the spin plane. Minimizing flexible motion of the wire booms requires that reorientation of the spacecraft spin axis be kept to a minimum: this is limited to attitude maneuvers to counteract the effects of gravity-gradient and apparent solar motion. Orbital maneuvers must therefore be carried out in essentially the nominal science attitude. These burns make use of a set of monopropellant hydrazine thrusters: two (of thrust 4.5 N) along the spin axis in each direction, and eight (of thrust 18 N) in the spin plane; the latter are pulsed at the spin rate to produce a net delta-v. An on-board accelerometer-based controller is used to accurately generate a commanded delta-v. Navigation makes use of a weak-signal GPS-based system: this allows signals to be received even when MMS is flying above the GPS orbits, producing a highly accurate determination of the four MMS orbits. This data is downlinked to the MMS Mission Operations Center (MOC) and used by the MOC Flight Dynamics Operations Area (FDOA) for maneuver design. These commands are then uplinked to the spacecraft and executed autonomously using the controller, with the ground monitoring the burns in real time.

satellite↗
NASA NTRS2011

Planetary Radar Imaging with the Deep-Space Network's 34 Meter Uplink Array

A coherent uplink array consisting of up to three 34-meter antennas of NASA's Deep Space Network has been developed for the primary purpose of increasing EIRP at the spacecraft. Greater EIRP ensures greater reach, higher uplink data rates for command and configuration control, as well as improved search and recovery capabilities during spacecraft emergencies. It has been conjectured that Doppler-delay radar imaging of lunar targets can be extended to planetary imaging, where the long baseline of the uplink array can provide greater resolution than a single antenna, as well as potentially higher EIRP. However, due to the well known R-4 loss in radar links, imaging of distant planets is a very challenging endeavor, requiring accurate phasing of the Uplink Array antennas, cryogenically cooled low-noise receiver amplifiers, and sophisticated processing of the received data to extract the weak echoes characteristic of planetary radar. This article describes experiments currently under way to image the planets Mercury and Venus, highlights improvements in equipment and techniques, and presents planetary images obtained to date with two 34 meter antennas configured as a coherently phased Uplink Array.

imaging↗
NASA NTRS2011

Planetary Radar Imaging with the Deep-Space Network's 34 Meter Uplink Array

A coherent Uplink Array consisting of two or three 34-meter antennas of NASA's Deep Space Network has been developed for the primary purpose of increasing EIRP at the spacecraft. Greater EIRP ensures greater reach, higher uplink data rates for command and configuration control, as well as improved search and recovery capabilities during spacecraft emergencies. It has been conjectured that Doppler-delay radar imaging of lunar targets can be extended to planetary imaging, where the long baseline of the uplink array can provide greater resolution than a single antenna, as well as potentially higher EIRP. However, due to the well known R4 loss in radar links, imaging of distant planets is a very challenging endeavor, requiring accurate phasing of the Uplink Array antennas, cryogenically cooled low-noise receiver amplifiers, and sophisticated processing of the received data to extract the weak echoes characteristic of planetary radar. This article describes experiments currently under way to image the planets Mercury and Venus, highlights improvements in equipment and techniques, and presents planetary images obtained to date with two 34 meter antennas configured as a coherently phased Uplink Array.

uplink array↗
NASA NTRS2014

ULSGEN (Uplink Summary Generator)

Uplink is an important part of spacecraft operations. Ensuring the accuracy of uplink content is essential to mission success. Before commands are radiated to the spacecraft, the command and sequence must be reviewed and verified by various teams. In most cases, this process requires collecting the command data, reviewing the data during a command conference meeting, and providing physical signatures by designated members of various teams to signify approval of the data. If commands or sequences are disapproved for some reason, the whole process must be restarted. Recording data and decision history is important for traceability reasons. Given that many steps and people are involved in this process, an easily accessible software tool for managing the process is vital to reducing human error which could result in uplinking incorrect data to the spacecraft. An uplink summary generator called ULSGEN was developed to assist this uplink content approval process. ULSGEN generates a web-based summary of uplink file content and provides an online review process. Spacecraft operations personnel view this summary as a final check before actual radiation of the uplink data. .

Wang, Y.-F.↗