Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “SDR”

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 127 records · Page 7

Research Supporting Satellite Communications Technology

This report describes the second year of research effort under the grant Research Supporting Satellite Communications Technology. The research program consists of two major projects: Fault Tolerant Link Establishment and the design of an Auto-Configurable Receiver. The Fault Tolerant Link Establishment protocol is being developed to assist the designers of satellite clusters to manage the inter-satellite communications. During this second year, the basic protocol design was validated with an extensive testing program. After this testing was completed, a channel error model was added to the protocol to permit the effects of channel errors to be measured. This error generation was used to test the effects of channel errors on Heartbeat and Token message passing. The C-language source code for the protocol modules was delivered to Goddard Space Flight Center for integration with the GSFC testbed. The need for a receiver autoconfiguration capability arises when a satellite-to-ground transmission is interrupted due to an unexpected event, the satellite transponder may reset to an unknown state and begin transmitting in a new mode. During Year 2, we completed testing of these algorithms when noise-induced bit errors were introduced. We also developed and tested an algorithm for estimating the data rate, assuming an NRZ-formatted signal corrupted with additive white Gaussian noise, and we took initial steps in integrating both algorithms into the SDR test bed at GSFC.

Horan Stephen↗

Modeling and Analysis of Space Based Transceivers

This paper presents the tool chain, methodology, and initial results of a study to provide a thorough, objective, and quantitative analysis of the design alternatives for space Software Defined Radio (SDR) transceivers. The approach taken was to develop a set of models and tools for describing communications requirements, the algorithm resource requirements, the available hardware, and the alternative software architectures, and generate analysis data necessary to compare alternative designs. The Space Transceiver Analysis Tool (STAT) was developed to help users identify and select representative designs, calculate the analysis data, and perform a comparative analysis of the representative designs. The tool allows the design space to be searched quickly while permitting incremental refinement in regions of higher payoff.

Reinhart, Richard C.↗

Modeling and Analysis of Space Based Transceivers

This paper presents the tool chain, methodology, and initial results of a study to provide a thorough, objective, and quantitative analysis of the design alternatives for space Software Defined Radio (SDR) transceivers. The approach taken was to develop a set of models and tools for describing communications requirements, the algorithm resource requirements, the available hardware, and the alternative software architectures, and generate analysis data necessary to compare alternative designs. The Space Transceiver Analysis Tool (STAT) was developed to help users identify and select representative designs, calculate the analysis data, and perform a comparative analysis of the representative designs. The tool allows the design space to be searched quickly while permitting incremental refinement in regions of higher payoff.

Moore, Michael S.↗

Space Telecommunications Radio System (STRS) Architecture Goals/Objectives and Level 1 Requirements

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.

Briones, Janette C.↗

Guidance, Navigation, and Control System Design in a Mass Reduction Exercise

Early Orion GN&C system designs optimized for robustness, simplicity, and utilization of commercially available components. During the System Definition Review (SDR), all subsystems on Orion were asked to re-optimize with component mass and steady state power as primary design metrics. The objective was to create a mass reserve in the Orion point of departure vehicle design prior to beginning the PDR analysis cycle. The Orion GN&C subsystem team transitioned from a philosophy of absolute 2 fault tolerance for crew safety and 1 fault tolerance for mission success to an approach of 1 fault tolerance for crew safety and risk based redundancy to meet probability allocations of loss of mission and loss of crew. This paper will discuss the analyses, rationale, and end results of this activity regarding Orion navigation sensor hardware, control effectors, and trajectory design.

Crain, Timothy↗

Space Telecommunications Radio System Software Architecture Concepts and Analysis

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.

Handler, Louis M.↗

NASA Supportability Engineering Implementation Utilizing DoD Practices and Processes

The Ares I design and development program made the determination early in the System Design Review Phase to utilize DoD ILS and LSA approach for supportability engineering as an integral part of the system engineering process. This paper is to provide a review of the overall approach to design Ares-I with an emphasis on a more affordable, supportable, and sustainable launch vehicle. Discussions will include the requirements development, design influence, support concept alternatives, ILS and LSA planning, Logistics support analyses/trades performed, LSA tailoring for NASA Ares Program, support system infrastructure identification, ILS Design Review documentation, Working Group coordination, and overall ILS implementation. At the outset, the Ares I Project initiated the development of the Integrated Logistics Support Plan (ILSP) and a Logistics Support Analysis process to provide a path forward for the management of the Ares-I ILS program and supportability analysis activities. The ILSP provide the initial planning and coordination between the Ares-I Project Elements and Ground Operation Project. The LSA process provided a system engineering approach in the development of the Ares-I supportability requirements; influence the design for supportability and development of alternative support concepts that satisfies the program operability requirements. The LSA planning and analysis results are documented in the Logistics Support Analysis Report. This document was required during the Ares-I System Design Review (SDR) and Preliminary Design Review (PDR) review cycles. To help coordinate the LSA process across the Ares-I project and between programs, the LSA Report is updated and released quarterly. A System Requirement Analysis was performed to determine the supportability requirements and technical performance measurements (TPMs). Two working groups were established to provide support in the management and implement the Ares-I ILS program, the Integrated Logistics Support Working Group (ILSWG) and the Logistics Support Analysis Record Working Group (LSARWG). The Ares I ILSWG is established to assess the requirements and conduct, evaluate analyses and trade studies associated with acquisition logistic and supportability processes and to resolve Ares I integrated logistics and supportability issues. It established a strategic collaborative alliance for coordination of Logistics Support Analysis activates in support of the integrated Ares I vehicle design and development of logistics support infrastructure. A Joint Ares I - Orion LSAR Working Group was established to: 1) Guide the development of Ares-I and Orion LSAR data and serve as a model for future Constellation programs, 2) Develop rules and assumptions that will apply across the Constellation program with regards to the program's LSAR development, and 3) Maintain the Constellation LSAR Style Guide.

Smith, David A.↗

Testing for the J-2X Upper Stage Engine

NASA selected the J-2X Upper Stage Engine in 2006 to power the upper stages of the Ares I crew launch vehicle and the Ares V cargo launch vehicle. Based on the proven Saturn J-2 engine, this new engine will provide 294,000 pounds of thrust and a specific impulse of 448 seconds, making it the most efficient gas generator cycle engine in history. The engine's guiding philosophy emerged from the Exploration Systems Architecture Study (ESAS) in 2005. Goals established then called for vehicles and components based, where feasible, on proven hardware from the Space Shuttle, commercial, and other programs, to perform the mission and provide an order of magnitude greater safety. Since that time, the team has made unprecedented progress. Ahead of the other elements of the Constellation Program architecture, the team has progressed through System Requirements Review (SRR), System Design Review (SDR), Preliminary Design Review (PDR), and Critical Design Review (CDR). As of February 2010, more than 100,000 development engine parts have been ordered and more than 18,000 delivered. Approximately 1,300 of more than 1,600 engine drawings were released for manufacturing. A major factor in the J-2X development approach to this point is testing operations of heritage J-2 engine hardware and new J-2X components to understand heritage performance, validate computer modeling of development components, mitigate risk early in development, and inform design trades. This testing has been performed both by NASA and its J-2X prime contractor, Pratt & Whitney Rocketdyne (PWR). This body of work increases the likelihood of success as the team prepares for testing the J-2X powerpack and first development engine in calendar 2011. This paper will provide highlights of J-2X testing operations, engine test facilities, development hardware, and plans.

Buzzell, James C.↗

From Paper to Production: An Update on NASA's Upper Stage Engine for Exploration

In 2006, NASA selected an evolved variant of the proven Saturn/Apollo J-2 upper stage engine to power the Ares I crew launch vehicle upper stage and the Ares V cargo launch vehicle Earth departure stage (EDS) for the Constellation Program. Any design changes needed by the new engine would be based where possible on proven hardware from the Space Shuttle, commercial launchers, and other programs. In addition to the thrust and efficiency requirements needed for the Constellation reference missions, it would be an order of magnitude safer than past engines. It required the J-2X government/industry team to develop the highest performance engine of its type in history and develop it for use in two vehicles for two different missions. In the attempt to achieve these goals in the past five years, the Upper Stage Engine team has made significant progress, successfully passing System Requirements Review (SRR), System Design Review (SDR), Preliminary Design Review (PDR), and Critical Design Review (CDR). As of spring 2010, more than 100,000 experimental and development engine parts have been completed or are in various stages of manufacture. Approximately 1,300 of more than 1,600 engine drawings have been released for manufacturing. This progress has been due to a combination of factors: the heritage hardware starting point, advanced computer analysis, and early heritage and development component testing to understand performance, validate computer modeling, and inform design trades. This work will increase the odds of success as engine team prepares for powerpack and development engine hot fire testing in calendar 2011. This paper will provide an overview of the engine development program and progress to date.

Kynard, Mike↗

The VIIRS Ocean Data Simulator Enhancements and Results

The VIIRS Ocean Science Team (VOST) has been developing an Ocean Data Simulator to create realistic VIIRS SDR datasets based on MODIS water-leaving radiances. The simulator is helping to assess instrument performance and scientific processing algorithms. Several changes were made in the last two years to complete the simulator and broaden its usefulness. The simulator is now fully functional and includes all sensor characteristics measured during prelaunch testing, including electronic and optical crosstalk influences, polarization sensitivity, and relative spectral response. Also included is the simulation of cloud and land radiances to make more realistic data sets and to understand their important influence on nearby ocean color data. The atmospheric tables used in the processing, including aerosol and Rayleigh reflectance coefficients, have been modeled using VIIRS relative spectral responses. The capabilities of the simulator were expanded to work in an unaggregated sample mode and to produce scans with additional samples beyond the standard scan. These features improve the capability to realistically add artifacts which act upon individual instrument samples prior to aggregation and which may originate from beyond the actual scan boundaries. The simulator was expanded to simulate all 16 M-bands and the EDR processing was improved to use these bands to make an SST product. The simulator is being used to generate global VIIRS data from and in parallel with the MODIS Aqua data stream. Studies have been conducted using the simulator to investigate the impact of instrument artifacts. This paper discusses the simulator improvements and results from the artifact impact studies.

Robinson, Wayne D.↗

NASA Planning for Orion Multi-Purpose Crew Vehicle Ground Operations

The NASA Orion Ground Processing Team was originally formed by the Kennedy Space Center (KSC) Constellation (Cx) Project Office's Orion Division to define, refine and mature pre-launch and post-landing ground operations for the Orion human spacecraft. The multidisciplined KSC Orion team consisted of KSC civil servant, SAIC, Productivity Apex, Inc. and Boeing-CAPPS engineers, project managers and safety engineers, as well as engineers from Constellation's Orion Project and Lockheed Martin Orion Prime contractor. The team evaluated the Orion design configurations as the spacecraft concept matured between Systems Design Review (SDR), Systems Requirement Review (SRR) and Preliminary Design Review (PDR). The team functionally decomposed prelaunch and post-landing steps at three levels' of detail, or tiers, beginning with functional flow block diagrams (FFBDs). The third tier FFBDs were used to build logic networks and nominal timelines. Orion ground support equipment (GSE) was identified and mapped to each step. This information was subsequently used in developing lower level operations steps in a Ground Operations Planning Document PDR product. Subject matter experts for each spacecraft and GSE subsystem were used to define 5th - 95th percentile processing times for each FFBD step, using the Delphi Method. Discrete event simulations used this information and the logic network to provide processing timeline confidence intervals for launch rate assessments. The team also used the capabilities of the KSC Visualization Lab, the FFBDs and knowledge of the spacecraft, GSE and facilities to build visualizations of Orion pre-launch and postlanding processing at KSC. Visualizations were a powerful tool for communicating planned operations within the KSC community (i.e., Ground Systems design team), and externally to the Orion Project, Lockheed Martin spacecraft designers and other Constellation Program stakeholders during the SRR to PDR timeframe. Other operations planning tools included Kaizen/Lean events, mockups and human factors analysis. The majority of products developed by this team are applicable as KSC prepares 21st Century Ground Systems for the Orion Multi-Purpose Crew Vehicle and Space Launch System.

Letchworth, Gary↗

Sptrace

Sptrace is a general-purpose space utilization tracing system that is conceptually similar to the commercial Purify product used to detect leaks and other memory usage errors. It is designed to monitor space utilization in any sort of heap, i.e., a region of data storage on some device (nominally memory; possibly shared and possibly persistent) with a flat address space. This software can trace usage of shared and/or non-volatile storage in addition to private RAM (random access memory). Sptrace is implemented as a set of C function calls that are invoked from within the software that is being examined. The function calls fall into two broad classes: (1) functions that are embedded within the heap management software [e.g., JPL's SDR (Simple Data Recorder) and PSM (Personal Space Management) systems] to enable heap usage analysis by populating a virtual time-sequenced log of usage activity, and (2) reporting functions that are embedded within the application program whose behavior is suspect. For ease of use, these functions may be wrapped privately inside public functions offered by the heap management software. Sptrace can be used for VxWorks or RTEMS realtime systems as easily as for Linux or OS/X systems.

Burleigh, Scott C.↗

High-Speed Isolation Board for Flight Hardware Testing

There is a need to provide a portable and cost-effective galvanic isolation between ground support equipment and flight hardware such that any unforeseen voltage differential between ground and power supplies is eliminated. An interface board was designed for use between the ground support equipment and the flight hardware that electrically isolates all input and output signals and faithfully reproduces them on each side of the interface. It utilizes highly integrated multi-channel isolating devices to minimize size and reduce assembly time. This single-board solution provides appropriate connector hardware and breakout of required flight signals to individual connectors as needed for various ground support equipment. The board utilizes multi-channel integrated circuits that contain transformer coupling, thereby allowing input and output signals to be isolated from one another while still providing high-fidelity reproduction of the signal up to 90 MHz. The board also takes in a single-voltage power supply input from the ground support equipment and in turn provides a transformer-derived isolated voltage supply to power the portion of the circuitry that is electrically connected to the flight hardware. Prior designs used expensive opto-isolated couplers that were required for each signal to isolate and were time-consuming to assemble. In addition, these earlier designs were bulky and required a 2U rack-mount enclosure. The new design is smaller than a piece of 8.5 ~11-in. (.22 ~28-mm) paper and can be easily hand-carried where needed. The flight hardware in question is based on a lineage of existing software-defined radios (SDRs) that utilize a common interface connector with many similar input-output signals present. There are currently four to five variations of this SDR, and more upcoming versions are planned based on the more recent design.

Yamamoto, Clifford K.↗

Post-Launch Calibration Support for VIIRS Onboard NASA NPP Spacecraft

The NPP Instrument Calibration Support Element (NICSE) is one of the elements within the NASA NPP Science Data Segment (SDS). The primary responsibility of NICSE is to independently monitor and evaluate on-orbit radiometric and geometric performance of the Visible Infrared Imaging Radiometer Suite (VIIRS) instrument and to validate its Sensor Data Record (SDR) [1]. The NICSE interacts and works closely with other SDS Product Evaluation and Analysis Tools Elements (PEATE) and the NPP Science Team (ST) and supports their on-orbit data product calibration and validation efforts. The NICSE also works closely with the NPP Instrument Calibration Support Team (NICST) during sensor pre-launch testing in ambient and thermal vacuum environment [2]. This paper provides an overview of NICSE VIIRS sensor post-launch calibration support with a focus on the use of sensor on-board calibrators (OBC) for the radiometric calibration and characterization. It presents the current status of NICSE post-launch radiometric calibration tool development effort based on its design requirements

Xiong, Xiaoxion↗

Zero-Copy Objects System

Zero-Copy Objects System software enables application data to be encapsulated in layers of communication protocol without being copied. Indirect referencing enables application source data, either in memory or in a file, to be encapsulated in place within an unlimited number of protocol headers and/or trailers. Zero-copy objects (ZCOs) are abstract data access representations designed to minimize I/O (input/output) in the encapsulation of application source data within one or more layers of communication protocol structure. They are constructed within the heap space of a Simple Data Recorder (SDR) data store to which all participating layers of the stack must have access. Each ZCO contains general information enabling access to the core source data object (an item of application data), together with (a) a linked list of zero or more specific extents that reference portions of this source data object, and (b) linked lists of protocol header and trailer capsules. The concatenation of the headers (in ascending stack sequence), the source data object extents, and the trailers (in descending stack sequence) constitute the transmitted data object constructed from the ZCO. This scheme enables a source data object to be encapsulated in a succession of protocol layers without ever having to be copied from a buffer at one layer of the protocol stack to an encapsulating buffer at a lower layer of the stack. For large source data objects, the savings in copy time and reduction in memory consumption may be considerable.

Burleigh, Scott C.↗

NPP VIIRS Early On-Orbit Geometric Performance

The NASA/NOAA Visible Infrared Imager Radiometer Suite (VIIRS) instrument on-board the Suomi National Polar-orbiting Partnership (NPP) satellite was launched in October, 2011. The instrument geometric performance includes sensor spatial response, band-to-band co-registration (BBR), and geolocation accuracy and precision. The geometric performance is an important aspect of sensor data record (SDR) calibration and validation. In this paper we will discuss geometric performance parameter characterization using the first seven-month of VIIRS' earth and lunar data, and compare with the at-launch performance using ground testing data and analysis of numerical modeling results as the first step in on-orbit geometric calibration and validation.

Wolfe, Robert E.↗

Experiments Program for NASA's Space Communications Testbed

NASA developed a testbed for communications and navigation that was launched to the International Space Station in 2012. The testbed promotes new software defined radio (SDR) technologies and addresses associated operational concepts for space-based SDRs, enabled by this first flight of NASA's Space Telecommunications Radio System (STRS) architecture standard. The experiments program consists of a mix of in-house and external experiments from partners in industry, academia, and government. The experiments will investigate key challenges in communications, networking, and global positioning system navigation both on the ground and on orbit. This presentation will discuss some of the key opportunities and challenges for the testbed experiments program.

Chelmins, David↗

CoNNeCT Antenna Positioning System Dynamic Simulator Modal Model Correlation

The National Aeronautics and Space Administration (NASA) developed an on-orbit, adaptable, Software Defined Radios (SDR)/Space Telecommunications Radio System (STRS)-based testbed facility to conduct a suite of experiments to advance technologies, reduce risk, and enable future mission capabilities on the International Space Station (ISS). The Communications, Navigation, and Networking reConfigurable Testbed (CoNNeCT) Project will provide NASA, industry, other Government agencies, and academic partners the opportunity to develop and field communications, navigation, and networking technologies in both the laboratory and space environment based on reconfigurable, software-defined radio platforms and the STRS Architecture. The CoNNeCT Payload Operations Nomenclature is SCAN Testbed, and this nomenclature will be used in all ISS integration, safety, verification, and operations documentation. The SCAN Testbed (payload) is a Flight Releasable Attachment Mechanism (FRAM) based payload that will launch aboard the Japanese H-II Transfer Vehicle (HTV) Multipurpose Exposed Pallet (EP-MP) to the International Space Station (ISS), and will be transferred to the Express Logistics Carrier 3 (ELC3) via Extravehicular Robotics (EVR). The SCAN Testbed will operate on-orbit for a minimum of two years.

Jones, Trevor M.↗