Search NASA⌕ Search

SEARCH · Search NASA

Results for “Telecommunications”

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 253 records · Page 14

Relay Telecommunications for the Coming Decade of Mars Exploration

Over the past decade, an evolving network of relay-equipped orbiters has advanced our capabilities for Mars exploration. NASA's Mars Global Surveyor, 2001 Mars Odyssey, and Mars Reconnaissance Orbiter (MRO), as well as ESA's Mars Express Orbiter, have provided telecommunications relay services to the 2003 Mars Exploration Rovers, Spirit and Opportunity, and to the 2007 Phoenix Lander. Based on these successes, a roadmap for continued Mars relay services is in place for the coming decade. MRO and Odyssey will provide key relay support to the 2011 Mars Science Laboratory (MSL) mission, including capture of critical event telemetry during entry, descent, and landing, as well as support for command and telemetry during surface operations, utilizing new capabilities of the Electra relay payload on MRO and the Electra-Lite payload on MSL to allow significant increase in data return relative to earlier missions. Over the remainder of the decade a number of additional orbiter and lander missions are planned, representing new orbital relay service providers and new landed relay users. In this paper we will outline this Mars relay roadmap, quantifying relay performance over time, illustrating planned support scenarios, and identifying key challenges and technology infusion opportunities.

Edwards, C.↗

Telecommunications Relay Support of the Mars Phoenix Lander Mission

The Phoenix Lander, first of NASA's Mars Scout missions, arrived at the Red Planet on May 25, 2008. From the moment the lander separated from its interplanetary cruise stage shortly before entry, the spacecraft could no longer communicate directly with Earth, and was instead entirely dependent on UHF relay communications via an international network of orbiting Mars spacecraft, including NASA's 2001 Mars Odyssey (ODY) and Mars Reconnaissance Orbiter (MRO) spacecraft, as well as ESA's Mars Express (MEX) spacecraft. All three orbiters captured critical event telemetry and/or tracking data during Phoenix Entry, Descent and Landing. During the Phoenix surface mission, ODY and MRO provided command and telemetry services, far surpassing the original data return requirements. The availability of MEX as a backup relay asset enhanced the robustness of the surface relay plan. In addition to telecommunications services, Doppler tracking observables acquired on the UHF link yielded an accurate position for the Phoenix landing site.

Edwards, Charles D., Jr.↗

Simulating Autonomous Telecommunication Networks for Space Exploration

Currently, most interplanetary telecommunication systems require human intervention for command and control. However, considering the range from near Earth to deep space missions, combined with the increase in the number of nodes and advancements in processing capabilities, the benefits from communication autonomy will be immense. Likewise, greater mission science autonomy brings the need for unscheduled, unpredictable communication and network routing. While the terrestrial Internet protocols are highly developed their suitability for space exploration has been questioned. JPL has developed the Multi-mission Advanced Communications Hybrid Environment for Test and Evaluation (MACHETE) tool to help characterize network designs and protocols. The results will allow future mission planners to better understand the trade offs of communication protocols. This paper discusses various issues with interplanetary network and simulation results of interplanetary networking protocols.

Segui, John S.↗

Considerations for the Next Revision of NASA's Space Telecommunications Radio System Architecture

Development of NASA's Software Defined Radio architecture, the Space Telecommunication Radio System (STRS), was initiated in 2004 with a goal of reducing the cost, risk and schedule when implementing Software Defined Radios (SDR) for National Aeronautics and Space Administration (NASA) space missions. Since STRS was first flown in 2012 on three Software Defined Radios on the Space Communication and Navigation (SCaN) Testbed, only minor changes have been made to the architecture. Multiple entities have since implemented the architecture and provided significant feedback for consideration for the next revision of the standard. The focus for the first set of updates to the architecture is items that enhance application portability. Items that require modifications to existing applications before migrating to the updated architecture will only be considered if there is compelling reasons to make the change. The significant suggestions that were further evaluated for consideration include expanding and clarifying the timing Application Programming Interfaces (APIs), improving handle name and identification (ID) definitions and use, and multiple items related to implementation of STRS Devices. In addition to ideas suggested while implementing STRS, SDR technology has evolved significantly and this impact to the architecture needs to be considered. These include incorporating cognitive concepts - learning from past decisions and making new decisions that the radio can act upon. SDRs are also being developed that do not contain a General Purpose Module - which is currently required for the platform to be STRS compliant. The purpose of this paper is to discuss the comments received, provide a summary of the evaluation considerations, and examine planned dispositions.

transmitters receivers↗

Future Standardization of Space Telecommunications Radio System with Core Flight System

NASA Glenn Research Center (GRC) is integrating the NASA Space Telecommunications Radio System (STRS) Standard with the Core Flight System (cFS), an avionics software operating environment. The STRS standard provides a common, consistent framework to develop, qualify, operate and maintain complex, reconfigurable and reprogrammable radio systems. The cFS is a flexible, open architecture that features a plugand- play software executive called the Core Flight Executive (cFE), a reusable library of software components for flight and space missions and an integrated tool suite. Together, STRS and cFS create a development environment that allows for STRS compliant applications to reference the STRS application programmer interfaces (APIs) that use the cFS infrastructure. These APIs are used to standardize the communication protocols on NASAs space SDRs. The cFS-STRS Operating Environment (OE) is a portable cFS library, which adds the ability to run STRS applications on existing cFS platforms. The purpose of this paper is to discuss the cFS-STRS OE prototype, preliminary experimental results performed using the Advanced Space Radio Platform (ASRP), the GRC S‑ band Ground Station and the SCaN (Space Communication and Navigation) Testbed currently flying onboard the International Space Station (ISS). Additionally, this paper presents a demonstration of the Consultative Committee for Space Data Systems (CCSDS) Spacecraft Onboard Interface Services (SOIS) using electronic data sheets (EDS) inside cFE. This configuration allows for the data sheets to specify binary formats for data exchange between STRS applications. The integration of STRS with cFS leverages mission-proven platform functions and mitigates barriers to integration with future missions. This reduces flight software development time and the costs of software-defined radio (SDR) platforms. Furthermore, the combined benefits of STRS standardization with the flexibility of cFS provide an effective, reliable and modular framework to minimize software development efforts for spaceflight missions.

space communications↗

Future Standardization of Space Telecommunications Radio System with Core Flight System

NASA Glenn Research Center (GRC) is integrating the NASA Space Telecommunications Radio System (STRS) Standard with the Core Flight System (cFS). The STRS standard provides a common, consistent framework to develop, qualify, operate and maintain complex, reconfigurable and reprogrammable radio systems. The cFS is a flexible, open architecture that features a plug-and-play software executive called the Core Flight Executive (cFE), a reusable library of software components for flight and space missions and an integrated tool suite. Together, STRS and cFS create a development environment that allows for STRS compliant applications to reference the STRS APIs through the cFS infrastructure. These APis are used to standardize the communication protocols on NASAs space SDRs. The cFE-STRS Operating Environment (OE) is a portable cFS library, which adds the ability to run STRS applications on existing cFS platforms. The purpose of this paper is to discuss the cFE-STRS OE prototype, preliminary experimental results performed using the Advanced Space Radio Platform (ASRP), the GRC Sband Ground Station and the SCaN (Space Communication and Navigation) Testbed currently flying onboard the International Space Station. Additionally, this paper presents a demonstration of the Consultative Committee for Space Data Systems (CCSDS) Spacecraft Onboard Interface Services (SOIS) using electronic data sheets inside cFE. This configuration allows for the data sheets to specify binary formats for data exchange between STRS applications. The integration of STRS with cFS leverages mission-proven platform functions and mitigates barriers to integration with future missions. This reduces flight software development time and the costs of software-defined radio (SDR) platforms. Furthermore, the combined benefits of STRS standardization with the flexibility of cFS provide an effective, reliable and modular framework to minimize software development efforts for spaceflight missions.

space communications↗

Programmable Logic Device (PLD) Design Description for the Integrated Power, Avionics, and Software (iPAS) Space Telecommunications Radio System (STRS) Radio

The Space Telecommunications Radio System (STRS) provides a common, consistent framework for software defined radios (SDRs) to abstract the application software from the radio platform hardware. The STRS standard aims to reduce the cost and risk of using complex, configurable and reprogrammable radio systems across NASA missions. To promote the use of the STRS architecture for future NASA advanced exploration missions, NASA Glenn Research Center (GRC) developed an STRS compliant SDR on a radio platform used by the Advance Exploration System program at the Johnson Space Center (JSC) in their Integrated Power, Avionics, and Software (iPAS) laboratory. At the conclusion of the development, the software and hardware description language (HDL) code was delivered to JSC for their use in their iPAS test bed to get hands-on experience with the STRS standard, and for development of their own STRS Waveforms on the now STRS compliant platform.The iPAS STRS Radio was implemented on the Reconfigurable, Intelligently-Adaptive Communication System (RIACS) platform, currently being used for radio development at JSC. The platform consists of a Xilinx ML605 Virtex-6 FPGA board, an Analog Devices FMCOMMS1-EBZ RF transceiver board, and an Embedded PC (Axiomtek eBox 620-110-FL) running the Ubuntu 12.4 operating system. Figure 1 shows the RIACS platform hardware. The result of this development is a very low cost STRS compliant platform that can be used for waveform developments for multiple applications.The purpose of this document is to describe the design of the HDL code for the FPGA portion of the iPAS STRS Radio particularly the design of the FPGA wrapper and the test waveform.

VHDL↗

Hardware Interface Description for the Integrated Power, Avionics, and Software (iPAS) Space Telecommunications Radio Ssystem (STRS) Radio

The Space Telecommunications Radio System (STRS) provides a common, consistent framework for software defined radios (SDRs) to abstract the application software from the radio platform hardware. The STRS standard aims to reduce the cost and risk of using complex, configurable and reprogrammable radio systems across NASA missions. To promote the use of the STRS architecture for future NASA advanced exploration missions, NASA Glenn Research Center (GRC) developed an STRS-compliant SDR on a radio platform used by the Advance Exploration System program at the Johnson Space Center (JSC) in their Integrated Power, Avionics, and Software (iPAS) laboratory. The iPAS STRS Radio was implemented on the Reconfigurable, Intelligently-Adaptive Communication System (RIACS) platform, currently being used for radio development at JSC. The platform consists of a Xilinx ML605 Virtex-6 FPGA board, an Analog Devices FMCOMMS1-EBZ RF transceiver board, and an Embedded PC (Axiomtek eBox 620-110-FL) running the Ubuntu 12.4 operating system. Figure 1 shows the RIACS platform hardware. The result of this development is a very low cost STRS compliant platform that can be used for waveform developments for multiple applications.The purpose of this document is to describe how to develop a new waveform using the RIACS platform and the Very High Speed Integrated Circuits (VHSIC) Hardware Description Language (VHDL) FPGA wrapper code and the STRS implementation on the Axiomtek processor.

Flight Computer↗

Waveform Developer's Guide for the Integrated Power, Avionics, and Software (iPAS) Space Telecommunications Radio System (STRS) Radio

The Space Telecommunications Radio System (STRS) provides a common, consistent framework for software defined radios (SDRs) to abstract the application software from the radio platform hardware. The STRS standard aims to reduce the cost and risk of using complex, configurable and reprogrammable radio systems across NASA missions. To promote the use of the STRS architecture for future NASA advanced exploration missions, NASA Glenn Research Center (GRC) developed an STRS-compliant SDR on a radio platform used by the Advance Exploration System program at the Johnson Space Center (JSC) in their Integrated Power, Avionics, and Software (iPAS) laboratory. The iPAS STRS Radio was implemented on the Reconfigurable, Intelligently-Adaptive Communication System (RIACS) platform, currently being used for radio development at JSC. The platform consists of a Xilinx(Trademark) ML605 Virtex(Trademark)-6 FPGA board, an Analog Devices FMCOMMS1-EBZ RF transceiver board, and an Embedded PC (Axiomtek(Trademark) eBox 620-110-FL) running the Ubuntu 12.4 operating system. The result of this development is a very low cost STRS compliant platform that can be used for waveform developments for multiple applications. The purpose of this document is to describe how to develop a new waveform using the RIACS platform and the Very High Speed Integrated Circuits (VHSIC) Hardware Description Language (VHDL) FPGA wrapper code and the STRS implementation on the Axiomtek processor.

Software Defined Radio↗

Integrated Power, Avionics, and Software (iPAS) Space Telecommunications Radio System (STRS) Radio User's Guide -- Advanced Exploration Systems (AES)

The Integrated Power, Avionics and Software (IPAS) software defined radio (SDR) was implemented on the Reconfigurable, Intelligently-Adaptive Communication System (RAICS) platform, for radio development at NASA Johnson Space Center. Software and hardware description language (HDL) code were delivered by NASA Glenn Research Center for use in the IPAS test bed and for development of their own Space Telecommunications Radio System (STRS) waveforms on the RAICS platform. The purpose of this document is to describe how to setup and operate the IPAS STRS Radio platform with its delivered test waveform.

space communications↗

Space Telecommunications Radio System (STRS) Architecture, Tutorial Part 1 - Overview

Space Telecommunications Radio System (STRS) Architecture Standard provides a NASA standard forsoftware-defined radio. The STRS architecture has been demonstrated in the Space Communications and Navigation(SCaN) Testbed on the International Space Station as well as associated ground station radios. The STRS ArchitectureTutorial Overview presents a general introduction to the STRS architecture standard developed at the NASA GlennResearch Center (GRC), describes some of the main elements for STRS compliance, and addresses some frequentlyasked questions.. The STRS architecture should be used as a base for many of NASA s future telecommunicationstechnologies. The presentation will provide a basic understanding of STRS.

Handler, Louis M.↗

Telecommunications End-to-End Systems Monitoring on TOPEX/POSEIDON: Tools and Techniques

The TOPEX/Poseidon Project Satellite Performance Analysis Team's (SPAT) roles and responsibilities have grown to include functions that are typically performed by other teams on JPL flight projects. In particular, SPAT Telecommunication's role has expanded beyond the nominal function of monitoring, assessing, characterizing, and trending the spacecraft RF/telecom subsystem to one of End-to-End Information Systems (EEIS) monitoring. This has been accomplished by taking advantage of the spacecraft and ground data system structures and protocols.

telecom↗

X/Ka-band one-meter deployable mesh reflector for Deep Space Network telecommunication

A deployable one meter mesh reflector compatible with 12U-class CubeSat is introduced for telecommunication. It is compatible with NASA’s deep-space network (DSN) at X-band (i.e., uplink: 7.145-7.19 GHz; downlink: 8.4-8.45 GHz) and Ka-band frequencies (i.e., uplink: 34.2–34.7 GHz; downlink: 31.8–32.3 GHz). Three right-handed circularly polarized (RHCP) antennas, both transmit and receive, are introduced here: X-band only, Ka-band only, and X/Ka-band.

Freebury, Gregg↗

NASA’s Interest in 3GPP Mobile Telecommunications Protocols for Near Earth Space and the Lunar Surface

In the next several years, NASA intends to return astronauts to the Moon through the Artemis Program. Under Artemis, NASA plans to collaborate with commercial and international partners to establish a long-term presence on the Moon. Near-term Artemis missions will be analogous but much more sophisticated versions of the last couple of Apollo missions. For example, the first area expected to be explored by an Artemis mission is near the south pole as opposed to the mid-latitudes visited by the Apollo astronauts, which makes direct communications with Earth more complicated. Lunar infrastructure will eventually be built over time by many organizations, public and private, to support sustained human exploration, science, and industrial activities on the Moon. A robust lunar communications and navigation infrastructure will be essential to realizing this long-term vision. Meanwhile, on Earth, major advances are being made as5G mobile telecommunications rollout across the globe. Furthermore, the 3rdGeneration Partnership Project (3GPP) is beginning to define future 6G capabilities. NASA envisions a lunar communications and navigation network with capabilities similar to those of communication networks we enjoy here on Earth. Building such a network will require participation by many organizations. NASA’s Tipping Point program seeks industry-developed space technologies that can both foster commercial space capabilities and benefit future NASA missions. This paper provides an overview of NASA’s interest in 3GPPanddescribescurrent work based on 3GPP standards within NASA or funded by NASA, such as Nokia’s upcoming Tipping Point demonstration of 4G/LTE on the lunar surface in early 2023.

Bernard L Edwards↗

3GPP Telecommunications Technology on the Moon

Under NASA’s Artemis program, NASA is planning to send astronauts back to the Moon in the next couple of years. Near term missions will be analogous but much more sophisticated versions of the last couple of Apollo missions. However, unlike Apollo, this time NASA intends to put the infrastructure in place to support long term human presence and eventual industrialization of the Moon. To make this vision a reality, NASA plans to collaborate with commercial and international partners as much as possible as opposed to developing, building, and operating equipment on its own. Lunar infrastructure will eventually be built over time by many organizations, public and private, to support sustained human exploration, science, and industrial activities. Obviously, this vision for the future will be impossible without a robust lunar communications and navigation system that can support many users with varying degrees of services. On Earth, most people are very familiar with the 3rd Generation Partnership Project (3GPP) 5G mobile telecommunications technology. NASA’s Space Technology Mission Directorate and NASA’s Space Communications and Navigation office would like to see a lunar communications and navigation network with similar capabilities to the cellular communication networks most of us enjoy today. Building such a network will require participation by many organizations. This paper will provide an overview of NASA’s interest in using 5G and beyond on the lunar surface; it will also describe current work based on 3GPP standards within NASA or funded by NASA, such as Nokia’s upcoming Tipping Point demonstration of 4G / LTE on the lunar surface.

Bernard Edwards↗

NASA's Deep Space Telecommunications Roadmap

This paper will present this roadmap, describe how it will support an increasing mission set while also providing significantly increased science data return, summarize the current state of key Ka-band and optical communications technologies, and identify critical path items in terms of technology developments, demonstrations, and mission users.

roadmap↗