SEARCH · Engineering Papers
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 Mars Telecommunications Orbiter (MTO) was intended to provide high-performance deep space relay links to landers, orbiters, sample-return, missions, and approaching spacecraft in the vicinity of Mars, to demonstrate interplanetary laser communications, to demonstrate autonomous navigation, and to carry out is own science investigations.
There are three primary drivers behind current investments in telecommunications information technology and navigation. One is finding ways to maximize the volume of science data returned from missions since i nstrument data generation often exceeds communication bandwidth. Another is to provide the necessary technology to enable networked spacecraft around Mars. The third driver is to enable more precise landing so in-situ vehicles can be placed in the more scientifically interesting regions. This paper describes the current NASA investments in these areas funded through the NASA Mars Technology Base Program NRA.
VHF Digital Link (VDL) has been identified as a method of communication between aircraft and ground stations in the Aeronautical Telecommunications Network (ATN). Three different modes of VDL have been suggested for implementation. Simulations were conducted to compare the data transfer capabilities of VDL Modes 2, 3, and 4. These simulations focus on up to 50 aircraft communicating with a single VDL ground station. The data traffic is generated by the standard File Transfer Protocol (FTP) and Hyper Text Transfer Protocol (HTTP) applications in the aircraft. Comparisons of the modes are based on the number of files and pages transferred and the response time.
This paper reports the findings of the simulation of the ATN (Aeronautical Telecommunications Network) for three typical average-sized U.S. airports and their associated air traffic patterns. The models of the protocols were designed to achieve the same functionality and meet the ATN specifications. The focus of this project is on the subnetwork and routing aspects of the simulation. To maintain continuous communication between the aircrafts and the ground facilities, a model based on mobile IP is used. The results indicate that continuous communication is indeed possible. The network can support two applications of significance in the immediate future FTP and HTTP traffic. Results from this simulation prove the feasibility of development of the ATN concept for AC/ATM (Advanced Communications for Air Traffic Management).
Deep Space Telecommunications Requirements: 1) Automated file transfer across inter-planetary distances; 2) Limited communication periods; 3) Reliable transport; 4) Delay and Disruption Tolerant; and 5) Asymmetric Data Channels.
This document reports the findings of the Mars Science and Telecommunications Orbiter (MSTO) Science Advocacy Group (SAG), which was convened by the Mars Exploration Program Analysis Group (MEPAG) and the Mars Exploration Office at JPL to identify and prioritize areas of Mars atmospheric and surface science objectives for Mars that can be accomplished from orbit on a MSTO like mission.
The Space Telecommunications Radio System (STRS) Architecture Requirements Document provides the basis for the development of an open architecture for NASA Software Defined Radios (SDRs) for space use. The main objective of this document is to evaluate the goals and objectives and high level (Level 1) requirements that have bearing on the design of the architecture. The goals and objectives will provide broad, fundamental direction and purpose. The high level requirements (Level 1) intend to guide the broader and longer term aspects aspects of the SDR Architecture and provide guidance for the development of level 2 requirements.
This paper describes an update of the Space Telecommunications Radio System (STRS) open architecture for NASA space based radios. The STRS architecture has been defined as a framework for the design, development, operation and upgrade of space based software defined radios, where processing resources are constrained. The architecture has been updated based upon reviews by NASA missions, radio providers, and component vendors. The STRS Standard prescribes the architectural relationship between the software elements used in software execution and defines the Application Programmer Interface (API) between the operating environment and the waveform application. Modeling tools have been adopted to present the architecture. The paper will present a description of the updated API, configuration files, and constraints. Minimum compliance is discussed for early implementations. The paper then closes with a summary of the changes made and discussion of the relevant alignment with the Object Management Group (OMG) SWRadio specification, and enhancements to the specialized signal processing abstraction.
The current implementation of the Telecommunications Protocol Processing Subsystem Using Reconfigurable Interoperable Gate Arrays (TRIGA) is equipped with CFDP protocol and CCSDS Telemetry and Telecommand framing schemes to replace the CPU intensive software counterpart implementation for reliable deep space communication. We present the hardware/software co-design methodology used to accomplish high data rate throughput. The hardware CFDP protocol stack implementation is then compared against the two recent flight implementations. The results from our experiments show that TRIGA offers more than 3 orders of magnitude throughput improvement with less than one-tenth of the power consumption.
NASA is developing an architecture standard for software-defined radios used in space- and ground-based platforms to enable commonality among radio developments to enhance capability and services while reducing mission and programmatic risk. Transceivers (or transponders) with functionality primarily defined in software (e.g., firmware) have the ability to change their functional behavior through software alone. This radio architecture standard offers value by employing common waveform software interfaces, method of instantiation, operation, and testing among different compliant hardware and software products. These common interfaces within the architecture abstract application software from the underlying hardware to enable technology insertion independently at either the software or hardware layer. This paper presents the initial Space Telecommunications Radio System (STRS) Architecture for NASA missions to provide the desired software abstraction and flexibility while minimizing the resources necessary to support the architecture.
The Space Telecommunications Radio System (STRS) project investigated various Software Defined Radio (SDR) architectures for Space. An STRS architecture has been selected that separates the STRS operating environment from its various waveforms and also abstracts any specialized hardware to limit its effect on the operating environment. The design supports software evolution where new functionality is incorporated into the radio. Radio hardware functionality has been moving from hardware based ASICs into firmware and software based processors such as FPGAs, DSPs and General Purpose Processors (GPPs). Use cases capture the requirements of a system by describing how the system should interact with the users or other systems (the actors) to achieve a specific goal. The Unified Modeling Language (UML) is used to illustrate the Use Cases in a variety of ways. The Top Level Use Case diagram shows groupings of the use cases and how the actors are involved. The state diagrams depict the various states that a system or object may be in and the transitions between those states. The sequence diagrams show the main flow of activity as described in the use cases.
Software-defined radio is a relatively new technology area, and industry consensus on terminology is not always consistent. Confusion exists when the various organizations and standards bodies define different radio terms associated with the actual amount of reconfigurability of the radios. The Space Telecommunications Radio System (STRS) Definitions and Acronyms Document provides the readers of the STRS documents a common understanding of the terminology used and how they will be applied to the STRS architecture.
The Space Telecommunication Radio System (STRS) standard is a Software Defined Radio (SDR) architecture standard developed by NASA. The goal of STRS is to reduce NASA s dependence on custom, proprietary architectures with unique and varying interfaces and hardware and support reuse of waveforms across platforms. The STRS project worked with members of the Object Management Group (OMG), Software Defined Radio Forum, and industry partners to leverage existing standards and knowledge. This collaboration included investigating the use of the OMG s Platform-Independent Model (PIM) SWRadio as the basis for an STRS PIM. This paper details the influence of the OMG technologies on the STRS update effort, findings in the STRS/SWRadio mapping, and provides a summary of the SDR Forum recommendations.
The Space Telecommunications Radio System (STRS) defines an open architecture for software defined radios. This document describes the testing methodology to aid in determining the degree of compliance to the STRS architecture. Non-compliances are reported to the software and hardware developers as well as the NASA project manager so that any non-compliances may be fixed or waivers issued. Since the software developers may be divided into those that provide the operating environment including the operating system and STRS infrastructure (OE) and those that supply the waveform applications, the tests are divided accordingly. The static tests are also divided by the availability of an automated tool that determines whether the source code and configuration files contain the appropriate items. Thus, there are six separate step-by-step test procedures described as well as the corresponding requirements that they test. The six types of STRS compliance tests are: STRS application automated testing, STRS infrastructure automated testing, STRS infrastructure testing by compiling WFCCN with the infrastructure, STRS configuration file testing, STRS application manual code testing, and STRS infrastructure manual code testing. Examples of the input and output of the scripts are shown in the appendices as well as more specific information about what to configure and test in WFCCN for non-compliance. In addition, each STRS requirement is listed and the type of testing briefly described. Attached is also a set of guidelines on what to look for in addition to the requirements to aid in the document review process.
This software demonstrates a working implementation of the NASA STRS (Space Telecommunications Radio System) architecture specification. This is a developing specification of software architecture and required interfaces to provide commonality among future NASA and commercial software-defined radios for space, and allow for easier mixing of software and hardware from different vendors. It provides required functions, and supports interaction with STRS-compliant simple test plug-ins ("waveforms"). All of it is programmed in "plain C," except where necessary to interact with C++ plug-ins. It offers a small footprint, suitable for use in JPL radio hardware. Future NASA work is expected to develop into fully capable software-defined radios for use on the space station, other space vehicles, and interplanetary probes.
The Mars Reconnaissance Orbiter (MRO) is an orbiting asset that performs remote sensing observations in order to characterize the surface, subsurface and atmosphere of Mars. To support upcoming NASA Mars Exploration Program Office objectives, MRO will be used as a relay communication link for the Mars Science Laboratory (MSL) mission during the MSL Entry, Descent and Landing sequence. To do so, MRO Navigation must synchronize the MRO Primary Science Orbit (PSO) with a set of target conditions requested by the MSL Navigation Team; this may be accomplished via propulsive maneuvers. This paper describes the MRO Navigation strategy for and operational performance of MSL EDL relay telecommunication support.
Radios today are evolving from awareness toward cognition. A software defined radio (SDR) provides the most capability for integrating autonomic decision making ability and allows the incremental evolution toward a cognitive radio. This cognitive radio technology will impact NASA space communications in areas such as spectrum utilization, interoperability, network operations, and radio resource management over a wide range of operating conditions. NASAs cognitive radio will build upon the infrastructure being developed by Space Telecommunication Radio System (STRS) SDR technology. This paper explores the feasibility of inserting cognitive capabilities in the NASA STRS architecture and the interfaces between the cognitive engine and the STRS radio. The STRS architecture defines methods that can inform the cognitive engine about the radio environment so that the cognitive engine can learn autonomously from experience, and take appropriate actions to adapt the radio operating characteristics and optimize performance.
A flight-qualified implementation of a Software Defined Radio (SDR) Operating Environment for the JPL-SDR built for the CoNNeCT Project has been developed. It is compliant with the NASA Space Telecommunications Radio System (STRS) Architecture Standard, and provides the software infrastructure for STRS compliant waveform applications. This software provides a standards-compliant abstracted view of the JPL-SDR hardware platform. It uses industry standard POSIX interfaces for most functions, as well as exposing the STRS API (Application Programming In terface) required by the standard. This software includes a standardized interface for IP components instantiated within a Xilinx FPGA (Field Programmable Gate Array). The software provides a standardized abstracted interface to platform resources such as data converters, file system, etc., which can be used by STRS standards conformant waveform applications. It provides a generic SDR operating environment with a much smaller resource footprint than similar products such as SCA (Software Communications Architecture) compliant implementations, or the DoD Joint Tactical Radio Systems (JTRS).