Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Firmware”

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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

Software Defined Radio Standard Architecture and its Application to NASA Space Missions

A software defined radio (SDR) architecture used in space-based platforms proposes to standardize certain aspects of radio development such as interface definitions, functional control and execution, and application software and firmware development. NASA has charted a team to develop an open software defined radio hardware and software architecture to support NASA missions and determine the viability of an Agency-wide Standard. A draft concept of the proposed standard has been released and discussed among organizations in the SDR community. Appropriate leveraging of the JTRS SCA, OMG's SWRadio Architecture and other aspects are considered. A standard radio architecture offers potential value by employing common waveform software instantiation, operation, testing and software maintenance. While software defined radios offer greater flexibility, they also poses challenges to the radio development for the space environment in terms of size, mass and power consumption and available technology. An SDR architecture for space must recognize and address the constraints of space flight hardware, and systems along with flight heritage and culture. NASA is actively participating in the development of technology and standards related to software defined radios. As NASA considers a standard radio architecture for space communications, input and coordination from government agencies, the industry, academia, and standards bodies is key to a successful architecture. The unique aspects of space require thorough investigation of relevant terrestrial technologies properly adapted to space. The talk will describe NASA's current effort to investigate SDR applications to space missions and a brief overview of a candidate architecture under consideration for space based platforms.

Andro, Monty↗
NASA NTRS2006

Space Telecommunications Radio Architecture (STRS)

A software defined radio (SDR) architecture used in space-based platforms proposes to standardize certain aspects of radio development such as interface definitions, functional control and execution, and application software and firmware development. NASA has charted a team to develop an open software defined radio hardware and software architecture to support NASA missions and determine the viability of an Agency-wide Standard. A draft concept of the proposed standard has been released and discussed among organizations in the SDR community. Appropriate leveraging of the JTRS SCA, OMG's SWRadio Architecture and other aspects are considered. A standard radio architecture offers potential value by employing common waveform software instantiation, operation, testing and software maintenance. While software defined radios offer greater flexibility, they also poses challenges to the radio development for the space environment in terms of size, mass and power consumption and available technology. An SDR architecture for space must recognize and address the constraints of space flight hardware, and systems along with flight heritage and culture. NASA is actively participating in the development of technology and standards related to software defined radios. As NASA considers a standard radio architecture for space communications, input and coordination from government agencies, the industry, academia, and standards bodies is key to a successful architecture. The unique aspects of space require thorough investigation of relevant terrestrial technologies properly adapted to space. The talk will describe NASA s current effort to investigate SDR applications to space missions and a brief overview of a candidate architecture under consideration for space based platforms.

Reinhart, Richard C.↗
NASA NTRS2007

NASA's SDR Standard: Space Telecommunications Radio System

A software defined radio (SDR) architecture used in space-based platforms proposes to standardize certain aspects of radio development such as interface definitions, functional control and execution, and application software and firmware development. NASA has charted a team to develop an open software defined radio hardware and software architecture to support NASA missions and determine the viability of an Agency-wide Standard. A draft concept of the proposed standard has been released and discussed among organizations in the SDR community. Appropriate leveraging of the JTRS SCA, OMG s SWRadio Architecture and other aspects are considered. A standard radio architecture offers potential value by employing common waveform software instantiation, operation, testing and software maintenance. While software defined radios offer greater flexibility, they also poses challenges to the radio development for the space environment in terms of size, mass and power consumption and available technology. An SDR architecture for space must recognize and address the constraints of space flight hardware, and systems along with flight heritage and culture. NASA is actively participating in the development of technology and standards related to software defined radios. As NASA considers a standard radio architecture for space communications, input and coordination from government agencies, the industry, academia, and standards bodies is key to a successful architecture. The unique aspects of space require thorough investigation of relevant terrestrial technologies properly adapted to space. The talk will describe NASA s current effort to investigate SDR applications to space missions and a brief overview of a candidate architecture under consideration for space based platforms.

Reinhart, Richard C.↗
NASA NTRS2008

Open Architecture Standard for NASA's Software-Defined Space Telecommunications Radio Systems

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.

Reinhart, Richard C.↗
NASA NTRS2008

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 NTRS2008

The Interplanetary Overlay Networking Protocol Accelerator

A document describes the Interplanetary Overlay Networking Protocol Accelerator (IONAC) an electronic apparatus, now under development, for relaying data at high rates in spacecraft and interplanetary radio-communication systems utilizing a delay-tolerant networking protocol. The protocol includes provisions for transmission and reception of data in bundles (essentially, messages), transfer of custody of a bundle to a recipient relay station at each step of a relay, and return receipts. Because of limitations on energy resources available for such relays, data rates attainable in a conventional software implementation of the protocol are lower than those needed, at any given reasonable energy-consumption rate. Therefore, a main goal in developing the IONAC is to reduce the energy consumption by an order of magnitude and the data-throughput capability by two orders of magnitude. The IONAC prototype is a field-programmable gate array that serves as a reconfigurable hybrid (hardware/ firmware) system for implementation of the protocol. The prototype can decode 108,000 bundles per second and encode 100,000 bundles per second. It includes a bundle-cache static randomaccess memory that enables maintenance of a throughput of 2.7Gb/s, and an Ethernet convergence layer that supports a duplex throughput of 1Gb/s.

Pang, Jackson↗
NASA NTRS2009

Oxygen Generation System Laptop Bus Controller Flight Software

The Oxygen Generation System Laptop Bus Controller Flight Software was developed to allow the International Space Station (ISS) program to activate specific components of the Oxygen Generation System (OGS) to perform a checkout of key hardware operation in a microgravity environment, as well as to perform preventative maintenance operations of system valves during a long period of what would otherwise be hardware dormancy. The software provides direct connectivity to the OGS Firmware Controller with pre-programmed tasks operated by on-orbit astronauts to exercise OGS valves and motors. The software is used to manipulate the pump, separator, and valves to alleviate the concerns of hardware problems due to long-term inactivity and to allow for operational verification of microgravity-sensitive components early enough so that, if problems are found, they can be addressed before the hardware is required for operation on-orbit. The decision was made to use existing on-orbit IBM ThinkPad A31p laptops and MIL-STD-1553B interface cards as the hardware configuration. The software at the time of this reporting was developed and tested for use under the Windows 2000 Professional operating system to ensure compatibility with the existing on-orbit computer systems.

Rowe, Chad↗
NASA NTRS2010

SEU/SET Tolerant Phase-Locked Loops

The phase-locked loop (PLL) is an old and widely used circuit for frequency and phase demodulation, carrier and clock recovery, and frequency synthesis [1]. Its implementations range from discrete components to fully integrated circuits and even to firmware or software. Often the PLL is a highly critical component of a system, as for example when it is used to derive the on-chip clock, but as of this writing no definitive single-event upset (SET)/single-event transient (SET) tolerant PLL circuit has been described. This chapter hopes to rectify that situation, at least in regard to PLLs that are used to generate clocks. Older literature on fault-tolerant PLLs deals with detection of a hard failure, which is recovered by replacement, repair, or manual restart of discrete component systems. Several patents exist along these lines (6349391, 6272647, and 7089442). A newer approach is to harden the parts of a PLL system, to one degree or another, such as by using a voltage-based charge pump or a triple modular redundant (TMR) voted voltage-controlled oscillator (VCO). A more comprehensive approach is to harden by triplication and voting (TMR) all the digital pieces (primarily the divider) of a frequency synthesis PLL, but this still leaves room for errors in the VCO and the loop filter. Instead of hardening or voting pieces of a system, such as a frequency synthesis system (i.e., clock multiplier), we will show how the entire system can be voted. There are two main ways of doing this, each with advantages and drawbacks. We will show how each has advantages in certain areas, depending on the lock acquisition and tracking characteristics of the PLL. Because of this dependency on PLL characteristics, we will briefly revisit the theory of PLLs. But first we will describe the characteristics of voters and their correct application, as some literature does not follow the voting procedure that guarantees elimination of errors. Additionally, we will find that voting clocks is a bit trickier than voting data where an infallible clock is assumed. It is our job here to produce (or recover) that assumed infallible clock!

Shuler, Robert L., Jr.↗
NASA NTRS2006

Orbiting GPS Receiver Modified to Track New L2C Signal

The L2C signal is a great step forward for civil applications of GPS, enabling high-accuracy dual-frequency measurements. Engineers from the Jet Propulsion Laboratory and ITT teamed to reprogram FPGA firmware and add tracking software on an orbiting receiver to track the new GPS L2C signal from SAC-C. SAC-C is an Argentinean science satellite and was launched in November 2000 with a BlackJack GPS receiver. This is a dual-frequency digital receiver with 48 tracking channels and four antennas. On SAC-C, it provides precise orbits, atmospheric occultation data, tests of GPS surface reflections, and serves as an orbiting test bed for new GPS development such as the L2C tracking reported here.

GPS receiver↗
NASA NTRS2008

Under the Radar: Trials and Tribulations of Landing on Mars

The Mars Phoenix Mission requires a ground-sensing radar altimeter/ velocimeter to meet touchdown velocity requirements During Phase C/D, the radar underwent a testing triptych: a) Aerial Testing, both captive carry and tethered drop tests (36 sorties, approx. 80 hrs). b) Testing with Electronic Ground Support Equipment (EGSE) on the bench (500+ hrs). c) Detailed Simulation including both RF physics and internal firmware logic (100,000+ simulated landings). All three venues were implemented to provide sufficient uniqueness and overlap to: a) Verify the radar is meeting its requirements. b) Validate radar performance within the flight system and environment. Significant discoveries were attributed to each of the three elements of the testing triptych, leading to greatly improved EDL system robustness. An overview of the testing triptych methodology, discoveries, and responses to them will be subsequently discussed.

Mars Phoenix Mission↗
NASA NTRS2010

Formal Methods at Intel - An Overview

Since the 1990s, Intel has invested heavily in formal methods, which are now deployed in several domains: hardware, software, firmware, protocols etc. Many different formal methods tools and techniques are in active use, including symbolic trajectory evaluation, temporal logic model checking, SMT-style combined decision procedures, and interactive higher-order logic theorem proving. I will try to give a broad overview of some of the formal methods activities taking place at Intel, and describe the challenges of extending formal verification to new areas and of effectively using multiple formal techniques in combination

Harrison, John↗
NASA NTRS2006

Modular, Microprocessor-Controlled Flash Lighting System

A microprocessor-controlled lighting system generates brief, precisely timed, high-intensity flashes of light for scientific imaging at frame rates up to about 1 kHz. The system includes an array of light-emitting diodes (LEDs) that are driven in synchronism with an externally generated timing signal (for example, a timing signal generated by a video camera). The light output can be varied in peak intensity, pulse duration, pulse delay, and pulse rate, all depending on the timing signal and associated externally generated control signals. The array of LEDs comprises as many as 16 LED panels that can be attached together. Each LED panel is a module consisting of a rectangular subarray of 10 by 20 LEDs of advanced design on a printed-circuit board in a mounting frame with a power/control connector. The LED panels are controlled by an LED control module that contains an AC-to-DC power supply, a control board, and 8 LED-panel driver boards. In prior LED panels, the LEDs are packaged at less than maximum areal densities in bulky metal housings that reduce effective active areas. In contrast, in the present LED panels, the LEDs are packed at maximum areal density so as to afford 100-percent active area and so that when panels are joined side by side to form the array, there are no visible seams between them and the proportion of active area is still 100 percent. Each panel produces an illuminance of .5 x 10( exp 4) lux at a distance of 5.8 in. (approx.1.6 cm). The LEDs are driven according to a pulse-width-modulation control scheme that makes it safe to drive the LEDs beyond their rated steady-state currents in order to generate additional light during short periods. The drive current and the pulse-width modulation for each LED panel can be controlled independently of those of the other 15 panels. The maximum allowable duration of each pulse of drive current is a function of the amount of overdrive, the total time to be spent in overdrive operation, and the limitations of the LEDs. The system is configured to limit the overdrive according to values specific to each type of LED in the array. These values are coded into firmware to prevent inadvertent damage to the LED panels.

Kiefer, Dwayne↗
NASA NTRS2009

Theorem Proving in Intel Hardware Design

For the past decade, a framework combining model checking (symbolic trajectory evaluation) and higher-order logic theorem proving has been in production use at Intel. Our tools and methodology have been used to formally verify execution cluster functionality (including floating-point operations) for a number of Intel products, including the Pentium(Registered TradeMark)4 and Core(TradeMark)i7 processors. Hardware verification in 2009 is much more challenging than it was in 1999 - today s CPU chip designs contain many processor cores and significant firmware content. This talk will attempt to distill the lessons learned over the past ten years, discuss how they apply to today s problems, outline some future directions.

O'Leary, John↗
NASA NTRS2008

Column Grid Array Rework for High Reliability

Due to requirements for reduced size and weight, use of grid array packages in space applications has become common place. To meet the requirement of high reliability and high number of I/Os, ceramic column grid array packages (CCGA) were selected for major electronic components used in next MARS Rover mission (specifically high density Field Programmable Gate Arrays). ABSTRACT The probability of removal and replacement of these devices on the actual flight printed wiring board assemblies is deemed to be very high because of last minute discoveries in final test which will dictate changes in the firmware. The questions and challenges presented to the manufacturing organizations engaged in the production of high reliability electronic assemblies are, Is the reliability of the PWBA adversely affected by rework (removal and replacement) of the CGA package? and How many times can we rework the same board without destroying a pad or degrading the lifetime of the assembly? To answer these questions, the most complex printed wiring board assembly used by the project was chosen to be used as the test vehicle, the PWB was modified to provide a daisy chain pattern, and a number of bare PWB s were acquired to this modified design. Non-functional 624 pin CGA packages with internal daisy chained matching the pattern on the PWB were procured. The combination of the modified PWB and the daisy chained packages enables continuity measurements of every soldered contact during subsequent testing and thermal cycling. Several test vehicles boards were assembled, reworked and then thermal cycled to assess the reliability of the solder joints and board material including pads and traces near the CGA. The details of rework process and results of thermal cycling are presented in this paper.

high reliability↗
NASA NTRS2006

Space Telecommunications Radio Architecture (STRS): Technical Overview

A software defined radio (SDR) architecture used in space-based platforms proposes to standardize certain aspects of radio development such as interface definitions, functional control and execution, and application software and firmware development. NASA has charted a team to develop an open software defined radio hardware and software architecture to support NASA missions and determine the viability of an Agency-wide Standard. A draft concept of the proposed standard has been released and discussed among organizations in the SDR community. Appropriate leveraging of the JTRS SCA, OMG s SWRadio Architecture and other aspects are considered. A standard radio architecture offers potential value by employing common waveform software instantiation, operation, testing and software maintenance. While software defined radios offer greater flexibility, they also poses challenges to the radio development for the space environment in terms of size, mass and power consumption and available technology. An SDR architecture for space must recognize and address the constraints of space flight hardware, and systems along with flight heritage and culture. NASA is actively participating in the development of technology and standards related to software defined radios. As NASA considers a standard radio architecture for space communications, input and coordination from government agencies, the industry, academia, and standards bodies is key to a successful architecture. The unique aspects of space require thorough investigation of relevant terrestrial technologies properly adapted to space. The talk will describe NASA's current effort to investigate SDR applications to space missions and a brief overview of a candidate architecture under consideration for space based platforms.

Reinhart, Richard C.↗
NASA NTRS2012

Space Telecommunications Radio System (STRS) Architecture Standard. Release 1.02.1

This document contains the NASA 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.

Reinhart, Richard C.↗
NASA NTRS2002

NASA Tech Briefs, April 2002

The contents include: 1) Application Briefs; 2) Sneak Preview of Sensors Expo; 3) The Complexity of the Diagnosis Problem; 4) Design Concepts for the ISS TransHab Module; 5) Characteristics of Supercritical Transitional Mixing Layers; 6) Electrometer for Triboelectric Evaluation of Materials; 7) Infrared CO2 Sensor With Built-In Calibration Chambers; 8) Solid-State Potentiometric CO Sensor; 9) Planetary Rover Absolute Heading Detection Using a Sun Sensor; 10) Concept for Utilizing Full Areas of STJ Photodetector Arrays; 11) Development of Cognitive Sensors; 12) Enabling Higher-Voltage Operation of SOl CMOS Transistors; 13) Estimating Antenna-Pointing Errors From Beam Squints; 14) Advanced-Fatigue-Crack-Growth and Fracture- Mechanics Program; 15) Software for Sequencing Spacecraft Actions; 16) Program Distributes and Tracks Organizational Memoranda; 16) Flat Membrane Device for Dehumidification of Air; 17) Inverted Hindle Mount Reduces Sag of a Large, Precise Mirror; 18) Heart-Pump-Outlet/Cannula Coupling; 19) Externally Triggered Microcapsules Release Drugs In Situ; 20) Combinatorial Drug Design Augmented by Information Theory; 21) Multiple-Path-Length Optical Absorbance Cell; 22) Model of a Fluidized Bed Containing a Mixture of Particles; 23) Refractive Secondary Concentrators for Solar Thermal Systems; 24) Cold Flow Calorimeter; 25) Methodology for Tracking Hazards and Predicting Failures; 26) Estimating Heterodyne-Interferometer Polarization Leakage; 27) An Efficient Algorithm for Propagation of Temporal- Constraint Networks; 28) Software for Continuous Replanning During Execution; 29) Surface-Launched Explorers for Reconnaissance/Scouting; 30) Firmware for a Small Motion-Control Processor; 31) Gear Bearings and Gear-Bearing Transmissions; and 32) Linear Dynamometer With Variable Stroke and Frequency.

Source record↗
NASA NTRS2011

Software Defined GPS Receiver for International Space Station

JPL is providing a software defined radio (SDR) that will fly on the International Space Station (ISS) as part of the CoNNeCT project under NASA's SCaN program. The SDR consists of several modules including a Baseband Processor Module (BPM) and a GPS Module (GPSM). The BPM executes applications (waveforms) consisting of software components for the embedded SPARC processor and logic for two Virtex II Field Programmable Gate Arrays (FPGAs) that operate on data received from the GPSM. GPS waveforms on the SDR are enabled by an L-Band antenna, low noise amplifier (LNA), and the GPSM that performs quadrature downconversion at L1, L2, and L5. The GPS waveform for the JPL SDR will acquire and track L1 C/A, L2C, and L5 GPS signals from a CoNNeCT platform on ISS, providing the best GPS-based positioning of ISS achieved to date, the first use of multiple frequency GPS on ISS, and potentially the first L5 signal tracking from space. The system will also enable various radiometric investigations on ISS such as local multipath or ISS dynamic behavior characterization. In following the software-defined model, this work will create a highly portable GPS software and firmware package that can be adapted to another platform with the necessary processor and FPGA capability. This paper also describes ISS applications for the JPL CoNNeCT SDR GPS waveform, possibilities for future global navigation satellite system (GNSS) tracking development, and the applicability of the waveform components to other space navigation applications.

software defined radio (SDR)↗