SEARCH · Search NASA

Results for “1553”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

52 records · Page 3

All sources NASA NTRS DOE OSTI

NASA NTRS2005

NASA SpaceWire Status

Three projects are developing SpaceWire upper layer protocols: JWST, LRO, GOES-R. JWST protocol development was complete before Protocol ID field was introduced to the standard. Commanding is done by using CCD5 packets tunneled through SpaceWire. Science Data packet is optimized for implementation specific requirements. Lunar Reconnaissance Orbiter (LRD) investigated using the SnP Rmap protocol but chose to use CCSDS tunneled through SpaceWire. GOES-R is using CCDS tunneled through SpaceWire with project developed Reliable Delivery protocol. Reliable Delivery protocol may be used to replace MIL-STD-1553 for other mission. CCDS is the native format for the software bus for many NASA GSFC missions and therefore it is a natural packet format to tunnel through SpaceWire.

Rakow, Glenn Parker↗

NASA NTRS2005

The Integrated Safety-Critical Advanced Avionics Communication and Control (ISAACC) System Concept: Infrastructure for ISHM

Integrated System Health Management (ISHM) architectures for spacecraft will include hard real-time, critical subsystems and soft real-time monitoring subsystems. Interaction between these subsystems will be necessary and an architecture supporting multiple criticality levels will be required. Demonstration hardware for the Integrated Safety-Critical Advanced Avionics Communication & Control (ISAACC) system has been developed at NASA Marshall Space Flight Center. It is a modular system using a commercially available time-triggered protocol, ?Tp/C, that supports hard real-time distributed control systems independent of the data transmission medium. The protocol is implemented in hardware and provides guaranteed low-latency messaging with inherent fault-tolerance and fault-containment. Interoperability between modules and systems of modules using the TTP/C is guaranteed through definition of messages and the precise message schedule implemented by the master-less Time Division Multiple Access (TDMA) communications protocol. "Plug-and-play" capability for sensors and actuators provides automatically configurable modules supporting sensor recalibration and control algorithm re-tuning without software modification. Modular components of controlled physical system(s) critical to control algorithm tuning, such as pumps or valve components in an engine, can be replaced or upgraded as "plug and play" components without modification to the ISAACC module hardware or software. ISAACC modules can communicate with other vehicle subsystems through time-triggered protocols or other communications protocols implemented over Ethernet, MIL-STD- 1553 and RS-485/422. Other communication bus physical layers and protocols can be included as required. In this way, the ISAACC modules can be part of a system-of-systems in a vehicle with multi-tier subsystems of varying criticality. The goal of the ISAACC architecture development is control and monitoring of safety critical systems of a manned spacecraft. These systems include spacecraft navigation and attitude control, propulsion, automated docking, vehicle health management and life support. ISAACC can integrate local critical subsystem health management with subsystems performing long term health monitoring. The ISAACC system and its relationship to ISHM will be presented.

Gwaltney, David A.↗

NASA NTRS2009

Wireless Avionics Packet to Support Fault Tolerance for Flight Applications

In this protocol and packet format, data traffic is monitored by all network interfaces to determine the health of transmitter and subsystems. When failures are detected, the network inter face applies its recover y policies to provide continued service despite the presence of faults. The protocol, packet format, and inter face are independent of the data link technology used. The current demonstration system supports both commercial off-the-shelf wireless connections and wired Ethernet connections. Other technologies such as 1553 or serial data links can be used for the network backbone. The Wireless Avionics packet is divided into three parts: a header, a data payload, and a checksum. The header has the following components: magic number, version, quality of service, time to live, sending transceiver, function code, payload length, source Application Data Interface (ADI) address, destination ADI address, sending node address, target node address, and a sequence number. The magic number is used to identify WAV packets, and allows the packet format to be updated in the future. The quality of service field allows routing decisions to be made based on this value and can be used to route critical management data over a dedicated channel. The time to live value is used to discard misrouted packets while the source transceiver is updated at each hop. This information is used to monitor the health of each transceiver in the network. To identify the packet type, the function code is used. Besides having a regular data packet, the system supports diagnostic packets for fault detection and isolation. The payload length specifies the number of data bytes in the payload, and this supports variable-length packets in the network. The source ADI is the address of the originating interface. This can be used by the destination application to identify the originating source of the packet where the address consists of a subnet, subsystem class within the subnet, a subsystem unit, and the local ADI number. The destination ADI is used to route the packet to its ultimate destination. At each hop, the sending interface uses the destination address to determine the next node for the data. The sending node is the node address of the interface that is broadcasting the packet. This field is used to determine the health of the subsystem that is sending the packet. In the case of a packet that traverses several intermediate nodes, it may be the node address of the intermediate node. The target node is the node address of the next hop for the packet. It may be an intermediate node, or the final destination for the packet. The sequence number is used to identify duplicate packets. Because each interface has multiple transceivers, the same packet will appear at both receivers. The sequence number allows the interface to correlate the reception and forward a single, unique packet for additional processing. The subnet field allows data traffic to be partitioned into segregated local networks to support large networks while keeping each subnet at a manageable size. This also keeps the routing table small enough so routing can be done by a simple table lookup in an FPGA device. The subsystem class identifies members of a set of redundant subsystems, and, in a hot standby configuration, all members of the subsystem class will receive the data packets. Only the active subsystem will generate data traffic. Specific units in a class of redundant units can be identified and, if the hot standby configuration is not used, packets will be directed to a specific subsystem unit.

Block, Gary L.↗

NASA NTRS2004

NASA Tech Briefs, November 2004

Topics include: Multifunction Imaging and Spectroscopic Instrument; Position-Finding Instrument Built Around a Magnetometer; Improved Measurement of Dispersion in an Optical Fiber; Probe for Sampling of Interstitial Fluid From Bone; Neuropsychological Testing of Astronauts; Method of Calibration for a Large Cathetometer System; Four-Channel PC/104 MIL-STD-1553 Circuit Board; Improved Method of Locating Defects in Wiring Insulation; Strobe Traffic Lights Warn of Approaching Emergency Vehicles; Improved Timing Scheme for Spaceborne Precipitation Radar; Concept for Multiple-Access Free-Space Laser Communications; Variable Shadow Screens for Imaging Optical Devices; Verifying Diagnostic Software; Initial Processing of Infrared Spectral Data; Activity-Centric Approach to Distributed Programming; Controlling Distributed Planning; New Material for Surface-Enhanced Raman Spectroscopy; Treated Carbon Nanofibers for Storing Energy in Aqueous KOH; Advanced Infant Car Seat Would Increase Highway Safety; Development of Biomorphic Flyers; Second-Generation Six-Limbed Experimental Robot; Miniature Linear Actuator for Small Spacecraft; Process for Making Single-Domain Magnetite Crystals; A New Process for Fabricating Random Silicon Nanotips; Resin-Transfer-Molding of a Tool Face; Improved Phase-Mask Fabrication of Fiber Bragg Gratings; Tool for Insertion of a Fiber-Optic Terminus in a Connector; Nanofluidic Size-Exclusion Chromatograph; Lightweight, Low-CTE Tubes Made From Biaxially Oriented LCPs; Using Redundancy To Reduce Errors in Magnetometer Readings; Compact Instrument for Measuring Profile of a Light Beam; Multilayer Dielectric Transmissive Optical Phase Modulator; Second-Generation Multi-Angle Imaging Spectroradiometer; Real-Time Adaptive Color Segmentation by Neural Networks; Research and Development in Optical Communications; Tests of Multibeam Scintillation Mitigation on Laser Uplinks; and Spaceborne Infrared Atmospheric Sounder.

Source record↗

NASA NTRS2003

NASA Tech Briefs, November 2003

Topics covered include: Computer Program Recognizes Patterns in Time-Series Data; Program for User-Friendly Management of Input and Output Data Sets; Noncoherent Tracking of a Source of a Data-Modulated Signal; Software for Acquiring Image Data for PIV; Detecting Edges in Images by Use of Fuzzy Reasoning; A Timer for Synchronous Digital Systems; Prototype Parts of a Digital Beam-Forming Wide-Band Receiver; High-Voltage Droplet Dispenser; Network Extender for MIL-STD-1553 Bus; MMIC HEMT Power Amplifier for 140 to 170 GHz; Piezoelectric Diffraction-Based Optical Switches; Numerical Modeling of Nanoelectronic Devices; Organizing Diverse, Distributed Project Information; Eigensolver for a Sparse, Large Hermitian Matrix; Modified Polar-Format Software for Processing SAR Data; e-Stars Template Builder; Software for Acoustic Rendering; Functionally Graded Nanophase Beryllium/Carbon Composites; Thin Thermal-Insulation Blankets for Very High Temperatures; Prolonging Microgravity on Parabolic Airplane Flights; Device for Locking a Control Knob; Cable-Dispensing Cart; Foam Sensor Structures Would be Self-Deployable and Survive Hard Landings; Real-Gas Effects on Binary Mixing Layers; Earth-Space Link Attenuation Estimation via Ground Radar Kdp; Wedge Heat-Flux Indicators for Flash Thermography; Measuring Diffusion of Liquids by Common-Path Interferometry; Zero-Shear, Low-Disturbance Optical Delay Line; Whispering-Gallery Mode-Locked Lasers; Spatial Light Modulators as Optical Crossbar Switches; Update on EMD and Hilbert-Spectra Analysis of Time Series; Quad-Tree Visual-Calculus Analysis of Satellite Coverage; Dyakonov-Perel Effect on Spin Dephasing in n-Type GaAs; Update on Area Production in Mixing of Supercritical Fluids; and Quasi-Sun-Pointing of Spacecraft Using Radiation Pressure.

Source record↗

NASA NTRS2011

FPGA for Power Control of MSL Avionics

A PLGT FPGA (Field Programmable Gate Array) is included in the LCC (Load Control Card), GID (Guidance Interface & Drivers), TMC (Telemetry Multiplexer Card), and PFC (Pyro Firing Card) boards of the Mars Science Laboratory (MSL) spacecraft. (PLGT stands for PFC, LCC, GID, and TMC.) It provides the interface between the backside bus and the power drivers on these boards. The LCC drives power switches to switch power loads, and also relays. The GID drives the thrusters and latch valves, as well as having the star-tracker and Sun-sensor interface. The PFC drives pyros, and the TMC receives digital and analog telemetry. The FPGA is implemented both in Xilinx (Spartan 3- 400) and in Actel (RTSX72SU, ASX72S). The Xilinx Spartan 3 part is used for the breadboard, the Actel ASX part is used for the EM (Engineer Module), and the pin-compatible, radiation-hardened RTSX part is used for final EM and flight. The MSL spacecraft uses a FC (Flight Computer) to control power loads, relays, thrusters, latch valves, Sun-sensor, and star-tracker, and to read telemetry such as temperature. Commands are sent over a 1553 bus to the MREU (Multi-Mission System Architecture Platform Remote Engineering Unit). The MREU resends over a remote serial command bus c-bus to the LCC, GID TMC, and PFC. The MREU also sends out telemetry addresses via a remote serial telemetry address bus to the LCC, GID, TMC, and PFC, and the status is returned over the remote serial telemetry data bus.

Wang, Duo↗

NASA NTRS2012

Lunar Reconnaissance Orbiter (LRO) Command and Data Handling Flight Electronics Subsystem

A document describes a high-performance, modular, and state-of-the-art Command and Data Handling (C&DH) system developed for use on the Lunar Reconnaissance Orbiter (LRO) mission. This system implements a complete hardware C&DH subsystem in a single chassis enclosure that includes a processor card, 48 Gbytes of solid-state recorder memory, data buses including MIL-STD-1553B, custom RS-422, SpaceWire, analog collection, switched power services, and interfaces to the Ka-Band and S-Band RF communications systems. The C&DH team capitalized on extensive experience with hardware and software with PCI bus design, SpaceWire networking, Actel FPGA design, digital flight design techniques, and the use of VxWorks for the real-time operating system. The resulting hardware architecture was implemented to meet the LRO mission requirements. The C&DH comprises an enclosure, a backplane, a low-voltage power converter, a single-board computer, a communications interface board, four data storage boards, a housekeeping and digital input/output board, and an analog data acquisition board. The interfaces between the C&DH and the instruments and avionics are connected through a SpaceWire network, a MIL-STD-1553 bus, and a combination of synchronous and asynchronous serial data transfers over RS-422 and LVDS (low-voltage differential-signaling) electrical interfaces. The C&DH acts as the spacecraft data system with an instrument data manager providing all software and internal bus scheduling, ingestion of science data, distribution of commands, and performing science operations in real time.

Nguyen, Quang↗

NASA NTRS2012

Multiplexer/Demultiplexer Loading Tool (MDMLT)

The purpose of the MDMLT is to improve the reliability and speed of loading multiplexers/demultiplexers (MDMs) in the Software Development and Integration Laboratory (SDIL) by automating the configuration management (CM) of the loads in the MDMs, automating the loading procedure, and providing the capability to load multiple or all MDMs concurrently. This loading may be accomplished in parallel, or single MDMs (remote). The MDMLT is a Web-based tool that is capable of loading the entire International Space Station (ISS) MDM configuration in parallel. It is able to load Flight Equivalent Units (FEUs), enhanced, standard, and prototype MDMs as well as both EEPROM (Electrically Erasable Programmable Read-Only Memory) and SSMMU (Solid State Mass Memory Unit) (MASS Memory). This software has extensive configuration management to track loading history, and the performance improvement means of loading the entire ISS MDM configuration of 49 MDMs in approximately 30 minutes, as opposed to 36 hours, which is what it took previously utilizing the flight method of S-Band uplink. The laptop version recently added to the MDMLT suite allows remote lab loading with the CM of information entered into a common database when it is reconnected to the network. This allows the program to reconfigure the test rigs quickly between shifts, allowing the lab to support a variety of onboard configurations during a single day, based on upcoming or current missions. The MDMLT Computer Software Configuration Item (CSCI) supports a Web-based command and control interface to the user. An interface to the SDIL File Transfer Protocol (FTP) server is supported to import Integrated Flight Loads (IFLs) and Internal Product Release Notes (IPRNs) into the database. An interface to the Monitor and Control System (MCS) is supported to control the power state, and to enable or disable the debug port of the MDMs to be loaded. Two direct interfaces to the MDM are supported: a serial interface (debug port) to receive MDM memory dump data and the calculated checksum, and the Small Computer System Interface (SCSI) to transfer load files to MDMs with hard disks. File transfer from the MDM Loading Tool to EEPROM within the MDM is performed via the MILSTD- 1553 bus, making use of the Real- Time Input/Output Processors (RTIOP) when using the rig-based MDMLT, and via a bus box when using the laptop MDMLT. The bus box is a cost-effective alternative to PC-1553 cards for the laptop. It is noted that this system can be modified and adapted to any avionic laboratory for spacecraft computer loading, ship avionics, or aircraft avionics where multiple configurations and strong configuration management of software/firmware loads are required.

Brewer, Lenox Allen↗

NASA NTRS2012

Plug-in Plan Tool v3.0.3.1

The role of PLUTO (Plug-in Port UTilization Officer) and the growth of the International Space Station (ISS) have exceeded the capabilities of the current tool PiP (Plug-in Plan). Its users (crew and flight controllers) have expressed an interest in a new, easy-to-use tool with a higher level of interactivity and functionality that is not bound by the limitations of Excel. The PiP Tool assists crewmembers and ground controllers in making real-time decisions concerning the safety and compatibility of hardware plugged into the UOPs (Utility Outlet Panels) onboard the ISS. The PiP Tool also provides a reference to the current configuration of the hardware plugged in to the UOPs, and enables the PLUTO and crew to test Plug-in locations for constraint violations (such as cable connector mismatches or amp limit violations), to see the amps and volts for an end item, to see whether or not the end item uses 1553 data, and the cable length between the outlet and the end item. As new equipment is flown or returned, the database can be updated appropriately as needed. The current tool is a macroheavy Excel spreadsheet with its own database and reporting functionality. The new tool captures the capabilities of the original tool, ports them to new software, defines a new dataset, and compensates for ever-growing unique constraints associated with the Plug-in Plan. New constraints were designed into the tool, and updates to existing constraints were added to provide more flexibility and customizability. In addition, there is an option to associate a "Flag" with each device that will let the user know there is a unique constraint associated with it when they use it. This helps improve the safety and efficiency of real-time calls by limiting the amount of "corporate knowledge" overhead that has to be trained and learned through use. The tool helps save time by automating previous manual processes, such as calculating connector types and deciding which cables are required and in what order.

Andrea-Liner, Kathleen E.↗

NASA NTRS2013

Small Projects Rapid Integration and Test Environment (SPRITE): Application for Increasing Robustness

Marshall Space Flight Center's (MSFC) Small Projects Rapid Integration and Test Environment (SPRITE) is a Hardware-In-The-Loop (HWIL) facility that provides rapid development, integration, and testing capabilities for small projects (CubeSats, payloads, spacecraft, and launch vehicles). This facility environment focuses on efficient processes and modular design to support rapid prototyping, integration, testing and verification of small projects at an affordable cost, especially compared to larger type HWIL facilities. SPRITE (Figure 1) consists of a "core" capability or "plant" simulation platform utilizing a graphical programming environment capable of being rapidly re-configured for any potential test article's space environments, as well as a standard set of interfaces (i.e. Mil-Std 1553, Serial, Analog, Digital, etc.). SPRITE also allows this level of interface testing of components and subsystems very early in a program, thereby reducing program risk.

Rakoczy, John↗

NASA NTRS2014

System-Level Testing of the Advanced Stirling Radioisotope Generator Engineering Hardware

To support future NASA deep space missions, a radioisotope power system utilizing Stirling power conversion technology was under development. This development effort was performed under the joint sponsorship of the Department of Energy and NASA, until its termination at the end of 2013 due to budget constraints. The higher conversion efficiency of the Stirling cycle compared with that of the Radioisotope Thermoelectric Generators (RTGs) used in previous missions (Viking, Pioneer, Voyager, Galileo, Ulysses, Cassini, Pluto New Horizons and Mars Science Laboratory) offers the advantage of a four-fold reduction in Pu-238 fuel, thereby extending its limited domestic supply. As part of closeout activities, system-level testing of flight-like Advanced Stirling Convertors (ASCs) with a flight-like ASC Controller Unit (ACU) was performed in February 2014. This hardware is the most representative of the flight design tested to date. The test fully demonstrates the following ACU and system functionality: system startup; ASC control and operation at nominal and worst-case operating conditions; power rectification; DC output power management throughout nominal and out-of-range host voltage levels; ACU fault management, and system command / telemetry via MIL-STD 1553 bus. This testing shows the viability of such a system for future deep space missions and bolsters confidence in the maturity of the flight design.

Deep space↗

NASA NTRS2015

Ethernet for Aerospace Applications - Ethernet Heads for the Skies

One of the goals of aerospace applications is to reduce the cost and complexity of avionic systems. Ethernet is a highly scalable, flexible, and popular protocol. The aerospace market is large, with a forecasted production of over 50,000 turbine-powered aircraft valued at $1.7 trillion between 2012 and 2022. Boeing estimates demand for commercial aircraft by 2033 to total over 36,000 with a value of over $5 trillion. In 2014 US airlines served over 750 million passengers and this is growing over 2% yearly. Electronic fly-by-wire is now used for all airliners and high performance aircraft. Although Ethernet has been widely used for four decades, its use in aerospace applications is just beginning to become common. Ethernet is the universal solution in commercial networks because of its high bandwidths, lower cost, openness, reliability, maintainability, flexibility, and interoperability. However, when Ethernet was designed applications with time-critical, safety relevant and deterministic requirements were not given much consideration. Many aerospace applications use a variety of communication architectures that add cost and complexity. Some of them are SpaceWire, MIL-STD-1553, Avionics Full Duplex Switched Ethernet (AFDX), and Time-Triggered Ethernet (TTE). Aerospace network designers desire to decrease the number of networks to reduce cost and effort while improving scalability, flexibility, openness, maintainability, and reliability. AFDX and TTE are being considered more for critical aerospace systems because they provide redundancy, failover protection, guaranteed timing, and frame priority and are based on Ethernet IEEE 802.3. This paper explores the use of AFDX and TTE for aerospace applications.

Ethernet↗

NASA NTRS2016

Implementing Ethernet Services on the Payload Executive Processor (PEP)

The Ethernet interface is more common and easier interface to implement for payload developers already familiar with Ethernet protocol in their labs. The Ethernet interface allows for a more distributed payload architecture. Connections can be placed in locations not serviced by the PEP 1553 bus. The Ethernet interface provides a new access port into the PEP so as to use the already existing services. Initial capability will include a subset of services with a plan to expand services later.

Pruett, David↗

NASA NTRS2019

The Space Debris Sensor Experiment

The Space Debris Sensor (SDS) is a NASA Class 1E technology demonstration external payload aboard the International Space Station (ISS). With approximately one square meter of detection area, the SDS is attached to the European Space Agency Columbus module facing the ISS velocity vector with minimal obstruction from ISS hardware. The SDS is the first flight demonstration of the Debris Resistive/Acoustic Grid Orbital NASA-Navy Sensor (DRAGONS) technology developed and matured over 10 years by the NASA Orbital Debris Program Office (ODPO), in concert with the DRAGONS consortium, to provide information on the sub-millimeter scale orbital debris environment. The SDS demonstrated the capacity to read 4 resistive grids at 1 Hz, 40 acoustic sensors at 500 kHz, and record and downlink impact data to the ground. Observable and derived data from the SDS could provide information to models that are critical to understanding risks the small debris environment poses to spacecraft in low Earth orbit. The technology demonstrated by the SDS is a major step forward in monitoring and characterizing the space debris environment. This paper will address the technical performance of the SDS during its operational lifetime and its realization of technical and scientific goals. The SDS was intended to operate for 3 years; however, the payload incurred multiple anomalies during its operational life. Subsequently termed “Anomaly #1,” the first was the symptomatic loss of low data rate 1553 channel command and telemetry. The second, Anomaly #2, was loss of all low- and medium-data rate (Ethernet) telemetry. Anomaly #2 proved to be unrecoverable, leading to loss of the payload after approximately 26 days on-board the ISS. Therefore, this paper also addresses the anomalies that occurred during operation of the SDS, their attribution, and their resolution. Lessons learned are described when relevant to anomaly identification, attribution, and resolution.

Anz-Meador, P.↗

NASA NTRS2016

Euclid Near Infrared Spectro Photometer instrument concept and first test results obtained for different breadboards models at the end of phase C

The Euclid mission objective is to understand why the expansion of the Universe is accelerating through by mapping the geometry of the dark Universe by investigating the distance-redshift relationship and tracing the evolution of cosmic structures. The Euclid project is part of ESA's Cosmic Vision program with its launch planned for 2020 (ref [1]). The NISP (Near Infrared Spectrometer and Photometer) is one of the two Euclid instruments and is operating in the near-IR spectral region (900- 2000nm) as a photometer and spectrometer. The instrument is composed of: - a cold (135K) optomechanical subsystem consisting of a Silicon carbide structure, an optical assembly (corrector and camera lens), a filter wheel mechanism, a grism wheel mechanism, a calibration unit and a thermal control system - a detection subsystem based on a mosaic of 16 HAWAII2RG cooled to 95K with their front-end readout electronic cooled to 140K, integrated on a mechanical focal plane structure made with molybdenum and aluminum. The detection subsystem is mounted on the optomechanical subsystem structure - a warm electronic subsystem (280K) composed of a data processing / detector control unit and of an instrument control unit that interfaces with the spacecraft via a 1553 bus for command and control and via Spacewire links for science data This presentation describes the architecture of the instrument at the end of the phase C (Detailed Design Review), the expected performance, the technological key challenges and preliminary test results obtained for different NISP subsystem breadboards and for the NISP Structural and Thermal model (STM).

Maciaszek, Thierry↗

NASA NTRS2019

ISS Science Payload Command & Data Handling

For decades, the International Space Station (ISS) has provided a distinctive platform in low Earth orbit for experimental research. In support of this platform is a family of avionics systems that enables reliable data distribution of the many science payloads installed, and future internal and external payloads. This poster provides an update to the ISS avionics hardware system architecture, including design change successes, test bed architecture, and performance upgrades in the operation of all ISS avionics. We conclude with an outlook on future avionics system enhancements required to support additional modules and payload expansions taking place on the ISS, and how these avionics systems translate to a lunar gateway.

1553↗