Search NASA⌕ Search

SEARCH · Search NASA

Results for “Mars Relay Spacecraft”

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.

133 records · Page 8
All sourcesNASA NTRSDOE OSTI
NASA NTRS2012

Entry, Descent, and Landing Communications for the 2011 Mars Science Laboratory

The Mars Science Laboratory (MSL), established as the most advanced rover to land on the surface of Mars to date, launched on November 26th, 2011 and arrived to the Martian Gale Crater during the night of August 5th, 2012 (PDT). MSL will investigate whether the landing region was ever suitable to support carbon-based life, and examine rocks, soil, and the atmosphere with a sophisticated suite of tools. This paper addresses the flight system requirement by which the vehicle transmitted indications of the following events using both X-band tones and UHF telemetry to allow identification of probable root causes should a mission anomaly have occurred: Heat-Rejection System (HRS) venting, completion of the cruise stage separation, turn to entry attitude, atmospheric deceleration, bank angle reversal commanded, parachute deployment, heatshield separation, radar ground acquisition, powered descent initiation, rover separation from the descent stage, and rover release. During Entry, Descent, and Landing (EDL), the flight system transmitted a UHF telemetry stream adequate to determine the state of the spacecraft (including the presence of faults) at 8 kbps initiating from cruise stage separation through at least one minute after positive indication of rover release on the surface of Mars. The flight system also transmitted X-band semaphore tones from Entry to Landing plus one minute although since MSL was occulted, as predicted, by Mars as seen from the Earth, Direct-To-Earth (DTE) communications were interrupted at approximately is approx. 5 min after Entry ( approximately 130 prior to Landing). The primary data return paths were through the Deep Space Network (DSN) for DTE and the existing Mars network of orbiting assets for UHF, which included the Mars Reconnaissance Orbiter (MRO), Mars Odyssey (ODY), and Mars Express (MEX) elements. These orbiters recorded the telemetry data stream and returned it back to Earth via the DSN. The paper also discusses the total power received during EDL and the robustness of the telecom design strategy used to ensure EDL communications coverage.

relay operations↗
NASA NTRS2011

Advanced Development of a Compact 5-15 lbf Lox/Methane Thruster for an Integrated Reaction Control and Main Engine Propulsion System

This paper describes the advanced development and testing of a compact 5 to 15 lbf LOX/LCH4 thruster for a pressure-fed integrated main engine and RCS propulsion system to be used on a spacecraft "vertical" test bed (VTB). The ability of the RCS thruster and the main engine to operate off the same propellant supply in zero-g reduces mass and improves mission flexibility. This compact RCS engine incorporates several features to dramatically reduce mass and parts count, to ease manufacturing, and to maintain acceptable performance given that specific impulse (Isp) is not the driver. For example, radial injection holes placed on the chamber body for easier drilling, and high temperature Haynes 230 were selected for the chamber over other more expensive options. The valve inlets are rotatable before welding allowing different orientations for vehicle integration. In addition, the engine design effort selected a coil-on-plug ignition system which integrates a relay and coil with the plug electrode, and moves some exciter electronics to avionics driver board. The engine injector design has small dribble volumes to target minimum pulse widths of 20 msec. and an efficient minimum impulse bit of less than 0.05 lbf-sec. The propellants, oxygen and methane, were chosen because together they are a non-toxic, Mars-forward, high density, space storable, and high performance propellant combination that is capable of pressure-fed and pump-fed configurations and integration with life support and power subsystems. This paper will present the results of the advanced development testing to date of the RCS thruster and the integration with a vehicle propulsion system.

Hurlbert, Eric A.↗
NASA NTRS2000

Nanorovers and Subsurface Explorers for Mars

Recent advances in microtechnology and mobile robotics have made it feasible to create extremely small automated or remote-controlled vehicles which open new application frontiers. One of these possible applications is the use of nanorovers (robotic vehicles with a mass of order one kilogram or less) in planetary exploration. NASA and Japan's Institute of Space and Astronautical Science (ISAS) are cooperating on the first mission to collect samples from the surface of an asteroid and return them to Earth for in-depth study. The ISAS MUSES-C mission will be launched on a Japanese launch vehicle in July 2002 from Japan toward a rendez-vous with the asteroid 1989ML in September 2003. A NASA-provided nanorover will conduct in-situ measurements on the surface. With a mass of about one kilogram, the rover experiment will be a direct descendant of the technology used to build the Sojourner rover. The rover will carry three science instruments: (1) a visible imaging camera, (2) a near-infrared point spectrometer, and (3) an alpha X ray spectrometer. The solar-powered rover will move around the surface of 1989ML collecting imagery data, which are complimentary to the spacecraft investigation. The imaging system will be capable of making surface texture, composition, and morphology measurements at resolutions better than one millimeter. The rover will transmit this data to the spacecraft for relay back to Earth. Due to the microgravity environment on 1989ML, the rover has been designed to right itself in case it flips over. Solar panels on four sides of the rover will ensure that enough power will always be available to the rover to activate the motors needed to turn over. Posable struts will allow the rover to position its chassis such that the camera can be pointed straight down at the surface or straight up at the sky.

Wilcox, Brian H.↗
NASA NTRS2018

Utilizing Testing Frameworks for Launch Control Systems Continuous Integration

Command and control software is an integral part of the launch procedure. The most important part of this type of software is its ability to communicate well with the user and relay information in a correctly formatted way such that the user can understand the data. There is a tool that aides the communication between the different parts of the system, and effectively, the user. This instrument is capable of taking several complex values and ensuring that they are correctly sorted into their distinctive message values and distributed properly among the different facets of the system. This tool will easily translate and publish the data inside of messages in the system to something that is readable and understandable. The tool also allows for transmission of the recorded data to the user, effectively ensuring the communication between different components of the system. As well as keeping track of messages and ensuring that the information contained within each of them reaches the correct location, this tool has the ability to keep track of its own statistics and determine how many messages passed in were erroneous and how many were successfully transmitted. It is able to check and see what the total message failure count is when an invalid message is given, as well as the number of different messages and their respective types passed into the tool. This tool is of great value to the new Space Launch System (SLS). As such, the tool must be thoroughly tested with test cases that, although improbable, are possible, where the tool may not function properly. Testing an interface this complex is necessary to ensure mission safety and create unlikely scenarios where the tool would work as intended, and stretch its limits to test that even under the most uncommon conditions it would still continue to function. This software will be an important part of the control system for the newest spacecraft which will fly deeper into space than humans have ever travelled. It will fly beyond the moon, into deep space to Mars and perhaps set the groundwork for a manned mission even further to create more opportunities for interplanetary and even interstellar travel by humans. This mission relies heavily on software and hardware to ensure the safety of the humans that will be on board and therefore must be checked, exhausting each and every different situation, such that there is not a doubt surrounding the well-being of the humans aboard the rocket. That is why testing is such an important part of the mission. It provides evidence that the systems aboard the rocket and on the launch pad are safe.

Unit Testing↗
NASA NTRSDate not supplied

Gateway Autonomy for Enabling Deep Space Exploration

The Gateway spacecraft is an important stepping-stone to exploration of the solar system, integrating commercial and international partners into a tightly coupled system, enabling cislunar activities, and implementing key technologies for missions to Mars. Autonomy is a capability area necessary to handle long communication outages where intervention from Earth is impossible, to prepare to operate with long communication delays that will be common in interplanetary travel, and to make spaceflight more affordable and accessible by reducing sustaining operations costs. The Gateway Concept of Operations states that one of Gateway’s goals is to “focus on infrastructure and systems that will allow autonomous operations aboard the Gateway with robotics, automated systems, advanced communications, and distributed computing.” Gateway’s Vehicle Systems Manager (VSM) and associated Autonomous Spacecraft Management Architecture (ASMA) are key products towards delivering autonomous capability. The primary functions of the control architecture are Mission Management and Timeline Execution, Resource Management, Fault Management, and Vehicle Control and Operation (VCO). In each of these areas, there is an initial level of capability to be delivered at launch, with plans to continue development and grow to greater capability. The initial deployment of VSM will focus on maintaining vehicle safety by focusing on full fault management capabilities and deploying only enough resource and timeline planning functionality to support that. The final deployment of VSM will add significant planning and control optimization functionality to support nominal operations for up to 21 days without ground support, even accommodating fault and failure conditions. While the VSM is the vehicle-level representation of autonomous reasoning, distributed automation is essential to provide the right scope and abstraction of information to process. Module and system support of automation and simplicity of interfaces are two important design paradigms that Gateway is focusing on to garner a systems approach to autonomy. Distribution of reasoning can increase complexity, so Gateway is also taking a strict hierarchical approach to information flow and decision making. VSM is not the only capability necessary to achieve an autonomous spacecraft. Robotics support for maintenance of the spacecraft will be essential to provide continued vehicle functionality even when crew is not present. Technical and programmatic challenges exist when implementing autonomous robotics operations. These challenges include sufficient network flexibility to support data transfer to the rest of the vehicle to coordinate module-to-module robotic walk-offs and finding the proper interfaces to allow sufficient dexterity. Communication system upgrades planned for Gateway include Delay Tolerant Networking to best utilize the complex network of relays that will be part of mature cislunar operations. Distributed computing and management will provide failure tolerance, robustness, and growth of capabilities while still allowing significant reuse of heritage software on heritage systems as well as reuse of common applications across a spacecraft to minimize new development, but this requires adherence to key standards and interfaces. The Gateway program has demonstrated significant progress towards these capabilities and has identified challenges other spacecraft developers should be aware of from the start.

Molly Anderson↗
NASA NTRSDate not supplied

Gateway Autonomy for Enabling Deep Space Exploration

The Gateway spacecraft is an important stepping-stone to exploration of the solar system, integrating commercial and international partners into a tightly coupled system, enabling cislunar activities, and implementing key technologies for missions to Mars. Autonomy is a capability area necessary to handle long communication outages where intervention from Earth is impossible, to prepare to operate with long communication delays that will be common in interplanetary travel, and to make spaceflight more affordable and accessible by reducing sustaining operations costs. The Gateway Concept of Operations states that one of Gateway’s goals is to “focus on infrastructure and systems that will allow autonomous operations aboard the Gateway with robotics, automated systems, advanced communications, and distributed computing.” Gateway’s Vehicle Systems Manager (VSM) and associated Autonomous Spacecraft Management Architecture (ASMA) are key products towards delivering autonomous capability. The primary functions of the control architecture are Mission Management and Timeline Execution, Resource Management, Fault Management, and Vehicle Control and Operation (VCO). In each of these areas, there is an initial level of capability to be delivered at launch, with plans to continue development and grow to greater capability. The initial deployment of VSM will focus on maintaining vehicle safety by focusing on full fault management capabilities and deploying only enough resource and timeline planning functionality to support that. The final deployment of VSM will add significant planning and control optimization functionality to support nominal operations for up to 21 days without ground support, even accommodating fault and failure conditions. While the VSM is the vehicle-level representation of autonomous reasoning, distributed automation is essential to provide the right scope and abstraction of information to process. Module and system support of automation and simplicity of interfaces are two important design paradigms that Gateway is focusing on to garner a systems approach to autonomy. Distribution of reasoning can increase complexity, so Gateway is also taking a strict hierarchical approach to information flow and decision making. VSM is not the only capability necessary to achieve an autonomous spacecraft. Robotics support for maintenance of the spacecraft will be essential to provide continued vehicle functionality even when crew is not present. Technical and programmatic challenges exist when implementing autonomous robotics operations. These challenges include sufficient network flexibility to support data transfer to the rest of the vehicle to coordinate module-to-module robotic walk-offs and finding the proper interfaces to allow sufficient dexterity. Communication system upgrades planned for Gateway include Delay Tolerant Networking to best utilize the complex network of relays that will be part of mature cislunar operations. Distributed computing and management will provide failure tolerance, robustness, and growth of capabilities while still allowing significant reuse of heritage software on heritage systems as well as reuse of common applications across a spacecraft to minimize new development, but this requires adherence to key standards and interfaces. The Gateway program has demonstrated significant progress towards these capabilities and has identified challenges other spacecraft developers should be aware of from the start.

Molly Anderson↗
NASA NTRS2014

The CCSDS Next Generation Space Data Link Protocol (NGSLP)

The CCSDS space link protocols i.e., Telemetry (TM), Telecommand (TC), Advanced Orbiting Systems (AOS) were developed in the early growth period of the space program. They were designed to meet the needs of the early missions, be compatible with the available technology and focused on the specific link environments. Digital technology was in its infancy and spacecraft power and mass issues enforced severe constraints on flight implementations. Therefore the Telecommand protocol was designed around a simple Bose, Hocquenghem, Chaudhuri (BCH) code that provided little coding gain and limited error detection but was relatively simple to decode on board. The infusion of the concatenated Convolutional and Reed-Solomon codes5 for telemetry was a major milestone and transformed telemetry applications by providing them the ability to more efficiently utilize the telemetry link and its ability to deliver user data. The ability to significantly lower the error rates on the telemetry links enabled the use of packet telemetry and data compression. The infusion of the high performance codes for telemetry was enabled by the advent of digital processing, but it was limited to earth based systems supporting telemetry. The latest CCSDS space link protocol, Proximity-1 was developed in early 2000 to meet the needs of short-range, bi-directional, fixed or mobile radio links characterized by short time delays, moderate but not weak signals, and short independent sessions. Proximity-1 has been successfully deployed on both NASA and ESA missions at Mars and is planned to be utilized by all Mars missions in development. A new age has arisen, one that now provides the means to perform advanced digital processing in spacecraft systems enabling the use of improved transponders, digital correlators, and high performance forward error correcting codes for all communications links. Flight transponders utilizing digital technology have emerged and can efficiently provide the means to make the next leap in performance for space link communications. Field Programmable Gate Arrays (FPGAs) provide the capability to incorporate high performance forward error correcting codes implemented within software transponders providing improved performance in data transfer, ranging, link security, and time correlation. Given these synergistic technological breakthroughs, the time has come to take advantage of them in applying them to both on going (e.g., command, telemetry) and emerging (e.g., space link security, optical communication) space link applications. However one of the constraining factors within the Data Link Layer in realizing these performance gains is the lack of a generic transfer frame format and common supporting services amongst the existing CCSDS link layer protocols. Currently each of the four CCSDS link layer protocols (TM, TC, AOS, and Proximity-1) have unique formats and services which prohibits their reuse across the totality of all space link applications of CCSDS member space agencies. For example, Mars missions. These missions implement their proximity data link layer using the Proximity-1 frame format and the services it supports but is still required to support the direct from Earth (TC) protocols and the Direct To Earth (AOS/TM) protocols. The prime purpose of this paper, is to describe a new general purpose CCSDS Data Link layer protocol, the NGSLP that will provide the required services along with a common transfer frame format for all the CCSDS space links (ground to/from space and space to space links) targeted for emerging missions after a CCSDS agency-wide coordinated date. This paper will also describe related options that can be included for the Coding and Synchronization sub-layer of the Data Link layer to extend the capacities of the link and additionally provide an independence of the transfer frame sub-layer from the coding sublayer. This feature will provide missions the option of running either the currently performed synchronous coding and transfer frame data link or an asynchronous coding/frame data link, in which the transfer frame length is independent of the block size of the code. The benefits from the elimination of this constraint (frame synchronized to the code block) will simplify the interface between the transponder and the data handling equipment and reduce implementation costs and complexities. The benefits include: inclusion of encoders/decoders into transmitters and receivers without regard to data link protocols, providing the ability to insert latency sensitive messages into the link to support launch, landing/docking, telerobotics. and Variable Coded Modulation (VCM). In addition the ability to transfer different sized frames can provide a backup for delivering stored anomaly engineering data simultaneously with real time data, or relaying of frames from various sources onto a trunk line for delivery to Earth.

Kazz, Greg J.↗