SEARCH · Search NASA
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.
The way a Proposed Deep Space Mission is designed should be linked to additional design parameters/ constraints such as the availability of the Deep Space Network to support communications. This paper explores this exact methodology by examining the launch opportunities of a simulated mission to Jupiter during a decade long timeframe.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
BioSentinel is an astrobiology small spacecraft mission. The payload consists of two parts, the first has optical and microfluidics sensors, and the second is a Linear Energy Transfer spectrometer that has the objective to measure deep space radiation from events such as coronal mass ejections. The goal of the mission is to observe potential DNA damage due to the radiation in heliocentric space on the living organism Saccharomyces cerevisiae, which is a budding yeast. Two types of this living organism are included in the payload. The first is a natural type that is more radiation tolerant, while the second is a mutant strain that has a deficiency in a gene that allows DNA repair once damage occurs. The impact caused by the radiation on the DNA is compared to an identical sample aboard the International Space Station, as well as another identical sample at a laboratory on the ground. The BioSentinel mission consists of a 6U CubeSat currently ,as of January 2024, active in heliocentric orbit. The spacecraft was launched aboard the first SLS flight as part of the Artemis-I campaign in November 2022. After successful deployment from the launch vehicle, it performed a lunar flyby with an altitude of 406 km. The delta-V imparted by the flyby provided the necessary energy to achieve a heliocentric orbit, in an Earth-trailing pattern. The navigation analysis consisted of a Kalman-filter that utilized data from the Deep Space Network and the ESA Estrack network. All those antennas were needed since the Artemis-1 campaign included the deployment of several other cubesats, therefore the scheduling process required more antenna assets than usual due to simultaneous demands from various missions. The processed tracking data was later also refined with a smoother in order to obtain a more accurate solution. The type of tracking data included TCP, Sequential Range, Doppler and Range formats. The solar radiation pressure coefficient, as well as the delta-V from the deployment and the flyby were modeled to obtain suitable solutions that could decrease the position and velocity uncertainties at several steps along the mission concept of operations. The final product each time resulted in updated ephemeris files that were used by the mission and the antenna networks as the mission progressed. Once in the final science orbit, the utilized antennas are only from the DSN network and the data format is bounded to just TCP. Regular orbit determination is performed, every two weeks. The spacecraft is in a nominal well-known orbit, performing regular operations. This paper includes an analysis of the final science orbit, the techniques and procedures utilized to perform orbit determination and a description of the overall navigation campaign produced during the mission and, more specifically, during the final science operations in Deep Space.
The heart of the spacecraft downlink is the flight data subsystem (FDS). The FDS combines the functions of science and engineering measurement control. The FDS can generate six principal telemetry formats, each of which may be transmitted directly to earth. Spacecraft engineering subsystems are considered, giving attention to the power subsystem, the attitude control subsystem, the propulsion subsystem, devices for temperature control, and the tracking subsystem. The mission operations system is also discussed together with the flight plan.
The Flight Dynamics Facility (FDF) at Goddard Space Flight Center (GSFC) provides spacecraft trajectory determination for a wide variety of National Aeronautics and Space Administration (NASA)-supported satellite missions, using the Tracking Data Relay Satellite System (TDRSS) and Ground Spaceflight and Tracking Data Network (GSTDN). To take advantage of computerized decision making processes that can be used in spacecraft navigation, the Orbit Determination Automation System (ODAS) was designed, developed, and implemented as a prototype system to automate orbit determination (OD) and orbit quality assurance (QA) functions performed by orbit operations. Based on a machine-resident generic schedule and predetermined mission-dependent QA criteria, ODAS autonomously activates an interface with the existing trajectory determination system using a batch least-squares differential correction algorithm to perform the basic OD functions. The computational parameters determined during the OD are processed to make computerized decisions regarding QA, and a controlled recovery process isactivated when the criteria are not satisfied. The complete cycle is autonomous and continuous. ODAS was extensively tested for performance under conditions resembling actual operational conditions and found to be effective and reliable for extended autonomous OD. Details of the system structure and function are discussed, and test results are presented.
The Flight Dynamics Facility (FDF) at Goddard Space Flight Center (GSFC) provides spacecraft trajectory determination for a wide variety of National Aeronautics and Space Administration (NASA)-supported satellite missions, using the Tracking Data Relay Satellite System (TDRSS) and Ground Spaceflight and Tracking Data Network (GSTDN). To take advantage of computerized decision making processes that can be used in spacecraft navigation, the Orbit Determination Automation System (ODAS) was designed, developed, and implemented as a prototype system to automate orbit determination (OD) and orbit quality assurance (QA) functions performed by orbit operations. Based on a machine-resident generic schedule and predetermined mission-dependent QA criteria, ODAS autonomously activates an interface with the existing trajectory determination system using a batch least-squares differential correction algorithm to perform the basic OD functions. The computational parameters determined during the OD are processed to make computerized decisions regarding QA, and a controlled recovery process is activated when the criteria are not satisfied. The complete cycle is autonomous and continuous. ODAS was extensively tested for performance under conditions resembling actual operational conditions and found to be effective and reliable for extended autonomous OD. Details of the system structure and function are discussed, and test results are presented.
The Tracking and Data System supported the deep space phases of the Pioneer 6, 7, 8, and 9 missions, with two spacecraft in an inward trajectory and two spacecraft in an outward trajectory from the earth in heliocentric orbits. During the period of this report, scientific instruments aboard each of the spacecraft continued to register information relative to interplanetary particles and fields, and radiometric data generated by the network continued to contribute to knowledge of the celestial mechanics of the solar system. In addition, to network support activity detail, network performance and special support activities are covered.
This paper documents a series of estimates of the orbital lifetime of the SEDS-2 flight configuration made prior to the mission. These estimates were made with program LTIME, which has been in use at MSFC for a number of years. Because of the unusual configuration of upper-stage/tether/endmass flown on this mission, and the type of assumptions and inputs used in LTIME, the effective area used in the drag calculation had to be estimated in an unusual way. The final pre-flight predicted lifetime was 28.35 days. In the actual flight, the tether was cut approximately 5 days into the mission. The instrumented endmass plus about 12 km of tether rapidly reentered the atmosphere, and the Delta II Second Stage plus the remaining 8 km of tether reentered on mission day 60. Tracking data was used to reconstruct reentry sequences for the two parts of the configuration after the cut. The predicted lifetimes for the endmass plus tether-fragment were in the range of 0.2 to 2.8 days, depending on the perigee altitudes assumed. The predicted lifetime of the upper-stage plus tether was 56.4 days, which corresponds to reentry on mission day 61, in good agreement with the actual reentry on day 60.
Problems inherent in the deployment and management of a worldwide tracking and data acquisition network to support the two Viking Orbiters and two Viking Landers simultaneously over 320 million kilometers (200 million miles) of deep space are discussed. Activities described include tracking coverage of the launch phase, the deep space operations during the long cruise phase that occupied approximately 11 months, and the implementation of the a vast worldwide network of tracking sttions and global communications systems. The performance of the personnel, hardware, and software involved in this vast undertaking are evaluated.
The NASA Space Network (SN) supports a variety of missions using the Tracking and Data Relay Satellite System (TDRSS), which includes ground stations in White Sands, New Mexico and Guam. A Space Network IP Services (SNIS) architecture is being developed to support future users with requirements for end-to-end Internet Protocol (IP) communications. This architecture will support all IP protocols, including Mobile IP, over TDRSS Single Access, Multiple Access, and Demand Access Radio Frequency (RF) links. This paper will describe this architecture and how it can enable Low Earth Orbiting IP satellite missions.
One aspect of my job as Payload Manager on the Advanced Composition Explorer (ACE) mission involved keeping track of what the different science teams were working on, and offering help where it was needed. At first it seemed like many of the scientists or their technical staff were not sure how safe it was to confide in me. Everybody knew I had spent most of my career with NASA at the Jet Propulsion Laboratory (JPL). All of my staff, initially four of them, came from JPL too. Left to our own devices, would we impose onerous NASA rules that could stifle innovation in the ACE (Advanced Composition Explorer) mission instrument development labs? The challenge to my team was getting the science groups to regard us as partners, or as people who could help them rather than as what they seemed to expect--a troop of requirements enforcers.
As the Mars Relay Network is in constant flux (missions and teams going through their daily workflow), it is imperative that users are aware of such state changes. For example, a change by an orbiter team can affect operations on a lander team. This software provides an ambient view of the real-time status of the Mars network. The Mars Relay Operations Service (MaROS) comprises a number of tools to coordinate, plan, and visualize various aspects of the Mars Relay Network. As part of MaROS, a feature set was developed that operates on several levels of the software architecture. These levels include a Web-based user interface, a back-end "ReSTlet" built in Java, and databases that store the data as it is received from the network. The result is a real-time event notification and management system, so mission teams can track and act upon events on a moment-by-moment basis. This software retrieves events from MaROS and displays them to the end user. Updates happen in real time, i.e., messages are pushed to the user while logged into the system, and queued when the user is not online for later viewing. The software does not do away with the email notifications, but augments them with in-line notifications. Further, this software expands the events that can generate a notification, and allows user-generated notifications. Existing software sends a smaller subset of mission-generated notifications via email. A common complaint of users was that the system-generated e-mails often "get lost" with other e-mail that comes in. This software allows for an expanded set (including user-generated) of notifications displayed in-line of the program. By separating notifications, this can improve a user's workflow.
Recent automated and advanced techniques developed at JPL have created a streamlined and fast-track approach to initial mission conceptualization and system architecture design, answering the need for rapid turnaround of trade studies for potential proposers, as well as mission and instrument study groups.
Pioneer 6 tracking data and RF performance from 1 July 1966 - 1 July 1969
The second generation Extreme Universe Space Observatory on a Super-Pressure Balloon (EUSO-SPB2) mission is on track to be approved by NASA for a long duration flight (up to 100 days) in 2023 from Wanaka, New Zealand. EUSO-SPB2 will monitor the night atmosphere of the Southern hemisphere from 33 km altitude to detect Ultra-High Energy Cosmic Rays (UHECRs) and search for astrophysical and cosmogenic neutrinos. EUSO-SPB2 features two telescopes, a Cherenkov (CT) and a Fluorescence (FT) Telescope. The hardware implementation and performance of the FT trigger logic were tested at the TurLab facility, hosted at the University of Turin. In conclusion, the tests proved the correct hardware implementation of the trigger logic and its ability to detect μs timescale transient signals.
Mariner IV mission to Mars - tracking and experimentation
Preflight and flight activities of Gemini 10 launch - tracking, crew training, mission profile, and times of major events