Electronic systems.
Spacecraft RF electronic systems covering voice communications, telemetry, trajectory measurements and digital command system
SPACECRAFT ELECTRONIC EQUIPMENT↗
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.
Fault protection techniques in JPL Spacecraft
While every JPL spacecraft requires some unique mission specific fault protection, there are many requirements which are common to all spacecraft configurations. These consist of protecting command and data processing & attitude control computers, protection against communication loss with the spacecraft, ensuring that safe external and internal temperature levels are maintained, and recovery from power overloads. Additionally, most JPL spacecraft are equipped with a general-purpose 'Safe Mode' response algorithm which configures the spacecraft to a lower power state which is safe and predictable so that diagnosis of more complex faults can be addressed by the Operations Team. This paper details the generic application of fault protection techniques which are implemented into most JPL spacecraft designs.
fault protection↗
The NASA Spacecraft Transponding Modem
A new deep space transponder is being developed by the Jet Propulsion Laboratory for NASA. The Spacecraft Transponding Modem (STM) implements the standard transponder functions and the channel service functions that have previously resided in spacecraft Command/Data Subsystems. The STM uses custom ASICs, MMICs, and MCMs to reduce the active device parts count to 70, mass to I kg, and volume to 524 cc. The first STMs will be flown on missions launching in the 2003 time frame. The STM tracks an X-band uplink signal and provides both X-band and Ka-band downlinks, either coherent or non-coherent with the uplink. A NASA standard Command Detector Unit is integrated into the STM, along with a codeblock processor and a hardware command decoder. The decoded command codeblocks are output to the spacecraft command/data subsystem. Virtual Channel 0 (VC-0) (hardware) commands are processed and output as critical controller (CRC) commands. Downlink telemetry is received from the spacecraft data subsystem as telemetry frames. The STM provides the following downlink coding options: the standard CCSDS (7-1/2) convolutional coding, ReedSolomon coding with interleave depths one and five, (15-1/6) convolutional coding, and Turbo coding with rates 1/3 and 1/6. The downlink symbol rates can be linearly ramped to match the G/T curve of the receiving station, providing up to a 1 dB increase in data return. Data rates range from 5 bits per second (bps) to 24 Mbps, with three modulation modes provided: modulated subcarrier (3 different frequencies provided), biphase-L modulated direct on carrier, and Offset QPSK. Also, the capability to generate one of four non-harmonically related telemetry beacon tones is provided, to allow for a simple spacecraft status monitoring scheme for cruise phases of missions. Three ranging modes are provided: standard turn around ranging, regenerative pseudo-noise (PN) ranging, and Differential One-way Ranging (DOR) tones. The regenerative ranging provides the capability of increasing the ground received ranging SNR by up to 30 dB. Two different avionics interfaces to the command/data subsystem's data bus are provided: a MIL STD 1553B bus or an industry standard PCI interface. Digital interfaces provide the capability to control antenna selection (e.g., switching between high gain and low gain antennas) and antenna pointing (for future steered Ka-band antennas).
Berner, Jeff B.↗
Nuclear reactor power for a space-based radar. SP-100 project
A space-based radar mission and spacecraft, using a 300 kWe nuclear reactor power system, has been examined, with emphasis on aspects affecting the power system. The radar antenna is a horizontal planar array, 32 X 64 m. The orbit is at 61 deg, 1088 km. The mass of the antenna with support structure is 42,000 kg; of the nuclear reactor power system, 8,300 kg; of the whole spacecraft about 51,000 kg, necessitating multiple launches and orbital assembly. The assembly orbit is at 57 deg, 400 km, high enough to provide the orbital lifetime needed for orbital assembly. The selected scenario uses six Shuttle launches to bring the spacecraft and a Centaur G upper-stage vehicle to assembly orbit. After assembly, the Centaur places the spacecraft in operational orbit, where it is deployed on radio command, the power system started, and the spacecraft becomes operational. Electric propulsion is an alternative and allows deployment in assembly orbit, but introduces a question of nuclear safety.
Bloomfield, Harvey↗
CASSIUS: The Cassini Uplink Scheduler
The Cassini Uplink Scheduler (CASSIUS) is cross-platform software used to generate a radiation sequence plan for commands being sent to the Cassini spacecraft. Because signals must travel through varying amounts of Earth's atmosphere, several different modes of constant telemetry rates have been devised. These modes guarantee that the spacecraft and the Deep Space Network agree with respect to the data transmission rate. However, the memory readout of a command will be lost if it occurs on a telemetry mode boundary. Given a list of spacecraft message files as well as the available telemetry modes, CASSIUS can find an uplink sequence that ensures safe transmission of each file. In addition, it can predict when the two on-board solid state recorders will swap. CASSIUS prevents data corruption by making sure that commands are not planned for memory readout during telemetry rate changes or a solid state recorder swap.
Cassini mission↗
Telecommunications from a lunar spacecraft.
Surveyor lunar spacecraft telecommunications system describing RF subsystem, command decoder and signal processing
TELECOMMUNICATION↗
Nodes
Nodes is a technology demonstration mission that is scheduled for launch to the International SpaceStation no earlier than Nov.19, 2015. The two Nodes satellites will be deployed from the Station in early 2016 todemonstrate new network capabilities critical to the operation of swarms of spacecraft. They will demonstrate the ability ofmulti spacecraft swarms to receive and distribute ground commands, exchange information periodically, andautonomously configure the network by determining which spacecraft should communicate with the ground each day ofthe mission.
Nodes↗
Pioneer Venus Orbiter Ultraviolet Spectrometer: Operations and Data Analysis
The Pioneer Venus spacecraft orbited Venus 5,055 times between 4th December 1978 and 6th October 1992, before entering Venus' atmosphere and burning up on the latter date. On 255 of these orbits, science operations were suspended because of superior conjunction (Venus' proximity to the Sun as seen from Earth). Of the remaining 4800 orbits, about 85% yielded good-quality OUVS science data; 15% were lost to various problems, including loss of uplink (commands) to and downlink (data) from the spacecraft, errors in commanding OUVS, and one or other of the two instrument anomalies mentioned below.
Stewart, A. I. F.↗
MSC Apollo 13 Investigation Team. Panel 6 - Related Systems Evaluation. Volume 3 - Command and Service Module
Analysis of spacecraft components and systems with potential for failures similar to Apollo 13 flight emergency
Source record↗
Optical distributed sensing and computation for a proposed flexible beam experiment
A new technology is being developed that supports distributed sensing and computation wherein crystal mediums are used with real-time holography to gather images that contain vibration and instantaneous geometry data for a spacecraft. Optical computation techniques are employed to process the image data and to compute commands to actuators located on the spacecraft. This paper presents an integrated sensor/processor design for an experiment to demonstrate this technology. A performance estimate for the design is presented in terms of the optical spatial bandwidth of the imaging system, as opposed to the temporal bandwidth. The advantages of an integrated optical sensor/processor relative to control of large spacecraft are addressed.
Welch, S. S.↗
Spacecraft technology. Volume VII - The Orbiting Astronomical Observatory
Design of command and data handling system for orbiting astronomical observatory, and scientific experiments for OAO spacecraft
SYSTEMS DESIGN↗
Flight Rule Design, Implementation, Verification, and Validation for the Psyche Mission
NASA Jet Propulsion Lab (JPL)’s upcoming mission Psyche will begin its journey to the asteroid (16) Psyche in late 2022 in an effort to better understand its origins and, in turn, better understand our own. Operating the spacecraft safely will require the dedicated efforts of a small team that understands the spacecraft’s operational constraints, as well as a set of powerful spacecraft models designed to catch command errors that can pose risks to mission success. One of the responsibilities of the operations team is to ensure adherence to a set of Flight Rules written by spacecraft and instrument experts that are designed to mitigate these risks. Psyche’s innovations in Flight Rule design principles and advancements in the tools and processes used to implement and check Flight Rules are discussed. A comparison of Psyche’s approach to Flight Rules to other JPL missions will provide lessons learned for future missions that must perform constraint checking during operations. Flight Rule development faces several major challenges. First, flight rule developers must work with Subject Matter Experts (SME) to write the rules in a way that captures the intent of the constraint in a straightforward, enforceable manner. Second, software implementers must correctly interpret flight rules into code so that it meets the original intent of the SME. Finally, a means must be provided for SMEs to validate flight rule implementations without requiring them to understand the underlying software. Innovative processes intended to efficiently close the loop between stakeholders and software developers are described, such as the use of test-driven development to provide stakeholders with easy-to-review implementations. New guidelines for flight rule writing, designed to address these challenges, are described for future missions to adopt and build upon. Psyche Mission System has a variety of new and heritage tools that improve in the Flight Rule validation and checking process. Psyche developed a powerful, new tool called RandSEQ and made significant improvements to Octopusjam, two valuable tools that aid the development of Flight Rule unit tests. Advancements in the models and processes for performing sequence validation with SEQuence GENerator (SEQGEN), the primary, high-heritage tool used for automated flight rule checks on Psyche, are described. The development of new software and the advancements to existing software put Psyche at the forefront of Flight Rule technology. All missions must perform detailed constraint checking, so a comparison of Psyche’s approach to some of these items to the approaches taken by other missions such as Dawn, M2020, and Europa Clipper is done, specifically to examine SME-developer communication, tools used, and development process. Lessons learned from this comparison will be provided.
Weise, Tim↗
Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality
With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.
Robert C Dempsey↗
Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality
With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.
Robert C. Dempsey↗
Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality
With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.
Robert C Dempsey↗
Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality
With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a unique private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed along with evolution of the system in preparation for the second uncrewed test flight. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies.
Robert C. Dempsey↗
Computing for Aiming a Spaceborne Bistatic-Radar Transmitter
BISTAT is a computer program for use in aiming a spaceborne bistatic-radar transmitting antenna at a remote planet that has an atmosphere, such that after refraction by the atmosphere and reflection from the surface of the planet, the radar signal travels toward a receiver on Earth. BISTAT includes an algorithm that neglects atmospheric refraction and calculates a specular-reflection point for a spacecraft at a given location. The specular-reflection point is then used as an initial guess for a modified limb-track algorithm that takes atmospheric refraction into account. The output of BISTAT for all spacecraft positions of interest constitutes a pointing profile; the output data are in the form of an inertial-vector file and a Doppler-residual file. The inertial-vector file is used to command the attitude of the spacecraft; the Doppler-residual file is used to determine a downlink frequency file for the receiver.
Rappaport, Nicole↗
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.
Spacecraft↗