Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “bus”

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 829 records · Page 46

Spacecraft Reed-Solomon downlink module

Apparatus and method for providing downlink frames to be transmitted from a spacecraft to a ground station. Each downlink frame includes a synchronization pattern and a transfer frame. The apparatus may comprise a monolithic Reed-Solomon downlink (RSDL) encoding chip coupled to data buffers for storing transfer frames. The RSKL chip includes a timing device, a bus interface, a timing and control unit, a synchronization pattern unit, and a Reed-Solomon encoding unit, and a bus arbiter.

Luong, Huy H.↗

Spacecraft power system architecture to mitigate spacecraft charging effects

A power system architecture for a spacecraft and a method of a power supply for a spacecraft are presented which take advantage of the reduced plasma interaction associated with positive ground high voltage photovoltaic arrays and provide a negative ground power supply for electrical loads of the spacecraft. They efficiently convert and regulate power to the load bus and reduce power system mass and complexity. The system and method ground the positive terminal of the solar arrays to the spacecraft hull, and using a power converter to invert the electric sign, permit a negative ground for the electrical distribution bus and electrical components. A number of variations including a load management system and a battery management system having charging and recharging devices are presented.

Manner, David B.↗

Network device interface for digitally interfacing data channels to a controller via a network

The present invention provides a network device interface and method for digitally connecting a plurality of data channels, such as sensors, actuators, and subsystems, to a controller using a network bus. The network device interface interprets commands and data received from the controller and polls the data channels in accordance with these commands. Specifically, the network device interface receives digital commands and data from the controller, and based on these commands and data, communicates with the data channels to either retrieve data in the case of a sensor or send data to activate an actuator. Data retrieved from the sensor is then converted by the network device interface into digital signals and transmitted back to the controller. In one advantageous embodiment, the network device interface uses a specialized protocol for communicating across the network bus that uses a low-level instruction set and has low overhead for data communication.

Ellerbrock, Philip J.↗

Network device interface for digitally interfacing data channels to a controller via a network

The present invention provides a network device interface and method for digitally connecting a plurality of data channels, such as sensors, actuators, and subsystems, to a controller using a network bus. The network device interface interprets commands and data received from the controller and polls the data channels in accordance with these commands. Specifically, the network device interface receives digital commands and data from the controller, and based on these commands and data, communicates with the data channels to either retrieve data in the case of a sensor or send data to activate an actuator. Data retrieved from the sensor is then converted by the network device interface into digital signals and transmitted back to the controller. In one advantageous embodiment, the network device interface uses a specialized protocol for communicating across the network bus that uses a low-level instruction set and has low overhead for data communication.

Ellerbrock, Philip J.↗

Network device interface for digitally interfacing data channels to a controller via a network

The present invention provides a network device interface and method for digitally connecting a plurality of data channels, such as sensors, actuators, and subsystems, to a controller using a network bus. The network device interface interprets commands and data received from the controller and polls the data channels in accordance with these commands. Specifically, the network device interface receives digital commands and data from the controller, and based on these commands and data, communicates with the data channels to either retrieve data in the case of a sensor or send data to activate an actuator. Data retrieved from the sensor is then converted by the network device interface into digital signals and transmitted back to the controller. In one advantageous embodiment, the network device interface is a state machine, such as an ASIC, that operates independent of a processor in communicating with the bus controller and data channels.

Ellerbrock, Philip J.↗

Network device interface for digitally interfacing data channels to a controller via a network

The present invention provides a network device interface and method for digitally connecting a plurality of data channels, such as sensors, actuators, and subsystems, to a controller using a network bus. The network device interface interprets commands and data received from the controller and polls the data channels in accordance with these commands. Specifically, the network device interface receives digital commands and data from the controller, and based on these commands and data, communicates with the data channels to either retrieve data in the case of a sensor or send data to activate an actuator. Data retrieved from the sensor is converted into digital signals and transmitted to the controller. In some embodiments, network device interfaces associated with different data channels coordinate communications with the other interfaces based on either a transition in a command message sent by the bus controller or a synchronous clock signal.

Ellerbrock, Philip J.↗

Guaranteeing Pointing Performance of the SDO Sun-Pointing Controllers in Light of Nonlinear Effects

The Solar Dynamics Observatory (SDO) mission is the first Space Weather Research Network mission, part of NASA s Living With a Star program.1 This program seeks to understand the changing Sun and its effects on the Solar System, life, and society. To this end, the SDO spacecraft will carry three Sun-observing instruments to geosynchronous orbit: Helioseismic and Magnetic Imager (HMI), led by Stanford University; Atmospheric Imaging Assembly (AIA), led by Lockheed Martin Space and Astrophysics Laboratory; and Extreme Ultraviolet Variability Experiment (EVE), led by the University of Colorado. Links describing the instruments in detail may be found through the SDO web site.2 The basic mission goals are to observe the Sun for a very high percentage of the 5-year mission (10-year goal) with long stretches of uninterrupted observations and with constant, high-data-rate transmission to a dedicated ground station. These goals guided the design of the spacecraft bus that will carry and service the three-instrument payload. At the time of this publication, the SDO spacecraft bus is well into the integration and testing phase at the NASA Goddard Space Flight Center (GSFC). A three-axis stabilized attitude control system (ACS) is needed both to point at the Sun accurately and to keep the roll about the Sun vector correctly positioned. The ACS has four reaction wheel modes and 2 thruster actuated modes. More details about the ACS in general and the control modes in particular can be found in Refs. [3-6]. All four of SDO s wheel-actuated control modes involve Sun-pointing controllers, as might be expected from such a mission. Science mode, during which most science data is collected, uses specialized guide telescopes to point accurately at the Sun. Inertial mode has two sub-modes, one tracks a Sun-referenced target orientation, and another maintains an absolute (star-referenced) target orientation, that both employ a Kalman filter to process data from a digital Sun sensor and two star trackers. However, this paper is concerned only with the other two modes: Safe Hold (SH) and Sun Acquisition (SA).

Starin, Scott R.↗

An Overview of Starfish: A Table-Centric Tool for Interactive Synthesis

Engineering is an interactive process that requires intelligent interaction at many levels. My thesis [1] advances an engineering discipline for high-level synthesis and architectural decomposition that integrates perspicuous representation, designer interaction, and mathematical rigor. Starfish, the software prototype for the design method, implements a table-centric transformation system for reorganizing control-dominated system expressions into high-level architectures. Based on the digital design derivation (DDD) system a designer-guided synthesis technique that applies correctness preserving transformations to synchronous data flow specifications expressed as co- recursive stream equations Starfish enhances user interaction and extends the reachable design space by incorporating four innovations: behavior tables, serialization tables, data refinement, and operator retiming. Behavior tables express systems of co-recursive stream equations as a table of guarded signal updates. Developers and users of the DDD system used manually constructed behavior tables to help them decide which transformations to apply and how to specify them. These design exercises produced several formally constructed hardware implementations: the FM9001 microprocessor, an SECD machine for evaluating LISP, and the SchemEngine, garbage collected machine for interpreting a byte-code representation of compiled Scheme programs. Bose and Tuna, two of DDD s developers, have subsequently commercialized the design derivation methodology at Derivation Systems, Inc. (DSI). DSI has formally derived and validated PCI bus interfaces and a Java byte-code processor; they further executed a contract to prototype SPIDER-NASA's ultra-reliable communications bus. To date, most derivations from DDD and DRS have targeted hardware due to its synchronous design paradigm. However, Starfish expressions are independent of the synchronization mechanism; there is no commitment to hardware or globally broadcast clocks. Though software back-ends for design derivation are limited to the DDD stream-interpreter, targeting synchronous or real-time software is not substantively different from targeting hardware.

Tsow, Alex↗

The Global Precipitation Measurement (GPM) Project

The GIobd Precipitation hleasurement (GPM) mission is an international cooperati~ee ffort to advance weather, climate, and hydrological predictions through space-based precipitation measurements. The Core Observatory will be a reference standard to uniform11 calibrate data from a constellatism of spacecraft with passive microuave sensors. GP3l mission data will be used for scientific research as well as societal applications. GPM is being developed under a partnership between the United States (US) National .Aeronautics and Space Administration (XASA) and the Japanese Aerospace and Exploration Agency (JAYA). NASA is developing the Core Observatory, a Low-Inclination Constellation Observatory, two GPM Rlicrowave Imager (GXII) instruments. Ground Validation System and Precipitation Processing System for the GPRl mission. JAXA will provide a Dual-frequency Precipitation Radar (DPR) for installation on the Core satellite and launch services for the Core Observatory. Other US agencies and international partners contribute to the GPkf mission by providing precipitation measurements obtained from their own spacecraft and,'or providing ground-based precipitation measurements to support ground validation activities. The GPM Core Observatory will be placed in a low earth orbit (-400 krn) with 65-degree inclination, in order to calibrate partner instruments in a variety of orbits. The Core Observatory accommodates 3 instruments. The GkfI instrument provides measurements of precipitation intensity and distribution. The DPR consists of Ka and Ku band instruments, and provides threedimensional measurements of cloud structure, precipitation particle size distribution and precipitation intensitj and distribution. The instruments are key drivers for GPM Core Observatory overall size (1 1.6m x 6.5m x 5.0m) and mass (3500kg), as well as the significant (-1 950U.3 power requirement. The Core Spacecraft is being built in-house at Goddard Space Flight Center. The spacecraft structure consists of an aluminum lower bus structure. composite upper bus structure, '-axis steerable High Gain Antenna System on a dual-hinged boom, and two deploy able solar arraq s. The propulsion system features twelve thrusters and a single Composite Overlv~apP ressure Vessel tank. The GPhl Core spacecraft is one of the first large spacecraft developed to be demiseable (i.e. burn up upon atmospheric reentry j. The spacecraft dernissable components-- structure. propulsion tank, lithium-ion battery, sotar array md reaction wheels. are a unique fcature.

Azarbarazin, Ardeshir Art↗

Re-Engineering the Tropical Rainfall Measuring Mission (TRMM) Satellite Utilizing Goddard Space Flight Center (GSFC) Mission Services Center (GMSEC) Middleware Based Technology to Enable Lights Out Operations and Autonomous Re-Dump of Lost Telemetry Data

The Tropical Rainfall Measuring Mission (TRMM) spacecraft was launched in November of 1996 in order to obtain unique three dimensional radar cross sectional observations of cloud structures with particular interest in hurricanes. The TRMM mission life was recently extended with current estimates that operations will continue through the 2012-2013 timeframe. Faced with this extended mission profile, the project has embarked on a technology refresh and re-engineering effort. TRMM has recently implemented a re-engineering effort to expand a middleware based messaging architecture to enable fully redundant lights-out of flight operations activities. The middleware approach is based on the Goddard Mission Services Evolution Center (GMSEC) architecture, tools and associated open-source Applications Programming Interface (API). Middleware based messaging systems are useful in spacecraft operations and automation systems because private node based knowledge (such as that within a telemetry and command system) can be broadcast on the middleware messaging bus and hence enable collaborative decisions to be made by multiple subsystems. In this fashion, private data is made public and distributed within the local area network and multiple nodes can remain synchronized with other nodes. This concept is useful in a fully redundant architecture whereby one node is monitoring the processing of the 'prime' node so that in the event of a failure the backup node can assume operations of the prime, without loss of state knowledge. This paper will review and present the experiences, architecture, approach and lessons learned of the TRMM re-engineering effort centered on the GMSEC middleware architecture and tool suite. Relevant information will be presented that relates to the dual redundant parallel nature of the Telemetry and Command (T and C) and Front-End systems and how these systems can interact over a middleware bus to achieve autonomous operations including autonomous commanding to recover missing science data during the same spacecraft contact.

Marius, Julio L.↗

A One Chip Hardened Solution for High Speed SpaceWire System Implementations. Session: Components

An Application Specific Integrated Circuit (ASIC) that implements the SpaceWire protocol has been developed in a radiation hardened 0.25 micron CMOS technology. This effort began in March 2003 as a joint development between the NASA Goddard Space Flight Center (GSFC) and BAE Systems. The BAE Systems SpaceWire ASIC is comprised entirely of reusable core elements, many of which are already flight-proven. It incorporates a router with 4 SpaceWire ports and two local ports, dual PC1 bus interfaces, a microcontroller, 32KB of internal memory, and a memory controller for additional external memory use. The SpaceWire cores are also reused in other ASICs under development. The SpaceWire ASIC is planned for use on the Geostationary Operational Environmental Satellites (GOES)-R, the Lunar Reconnaissance Orbiter (LRO) and other missions. Engineering and flight parts have been delivered to programs and users. This paper reviews the SpaceWire protocol and those elements of it that have been built into the current and next SpaceWire reusable cores and features within the core that go beyond the current standard and can be enabled or disabled by the user. The adaptation of SpaceWire to BAE Systems' On Chip Bus (OCB) for compatibility with the other reusable cores will be reviewed and highlighted. Optional configurations within user systems and test boards will be shown. The physical implementation of the design will be described and test results from the hardware will be discussed. Application of this ASIC and other ASICs containing the SpaceWire cores and embedded microcontroller to Plug and Play and reconfigurable implementations will be described. Finally, the BAE Systems roadmap for SpaceWire developments will be updated, including some products already in design as well as longer term plans.

Marshall, Joseph R.↗

Conceptual Design of the TPF-O SC Buses

The Terrestrial Planet Finder - Occulter (TPF-O) mission has two Spacecraft (SC) buses, one for a space telescope and the other for a formation-flying occulter. SC buses typically supply the utilities (support structures, propulsion, attitude control, power, communications, etc) required by the payloads. Unique requirements for the occulter SC bus are to provide the large delta V required for the slewing maneuvers of the occulter, and comunications for formation flying. The TPF-O telescope SC bus shares some key features of the one for the Hubble Space Telescope (HST): both support space telescopes designed to observe in the visible to near infrared range of wavelengths with comparable primary mirror apertures (2.4 m for HST, 2.4 - 4.0 m for TPF-O). However, TPF-O is expected to have a Wide Field Camera (WFC) with a Field of View (FOV) much larger than that of HST. Ths WFC is also expected to provide fine guidance. TPF-O is designed to operate in an orbit around the Sun-Earth Lagrange 2 (SEL2) point. The longer communications range to SEL2 and the large science FOV require higher performance communications than HST. Maintaining a SEL2 orbit requires TPF-O, unlike HST, to have a propulsion system. The velocity required for reachng SEL2 and the limited capabilities of affordable launch vehicles require both TPF-O elements to have compact, low-mass designs. Finally, it is possible that TPF-O may utilize a modular design derived fiom that of HST to allow servicing in the SEL2 orbit.

Purves, Lloyd R.↗

Network-Attached Solid-State Recorder Architecture

A document discusses placing memory modules on the high-speed serial interconnect, which is used by a spacecraft s computer elements for inter-processor communications, to allow all multiple computer system architectures to access the spacecraft data storage at the same time. Each memory board is identical electrically and receives its bus ID upon connection to the system. The computer elements are configured in a similar fashion. The architecture allows for multiple memory boards to be accessed simultaneously by different computer elements, and results in a scalable, strong, fault-tolerant system. The IEEE-1393 ring bus can be routed so that multiple card failures can occur and the mass memory storage will still function.

Cox, Brian↗

Replication of Space-Shuttle Computers in FPGAs and ASICs

A document discusses the replication of the functionality of the onboard space-shuttle general-purpose computers (GPCs) in field-programmable gate arrays (FPGAs) and application-specific integrated circuits (ASICs). The purpose of the replication effort is to enable utilization of proven space-shuttle flight software and software-development facilities to the extent possible during development of software for flight computers for a new generation of launch vehicles derived from the space shuttles. The replication involves specifying the instruction set of the central processing unit and the input/output processor (IOP) of the space-shuttle GPC in a hardware description language (HDL). The HDL is synthesized to form a "core" processor in an FPGA or, less preferably, in an ASIC. The core processor can be used to create a flight-control card to be inserted into a new avionics computer. The IOP of the GPC as implemented in the core processor could be designed to support data-bus protocols other than that of a multiplexer interface adapter (MIA) used in the space shuttle. Hence, a computer containing the core processor could be tailored to communicate via the space-shuttle GPC bus and/or one or more other buses.

Ferguson, Roscoe C.↗

Improved Signal Chains for Readout of CMOS Imagers

An improved generic design has been devised for implementing signal chains involved in readout from complementary metal oxide/semiconductor (CMOS) image sensors and for other readout integrated circuits (ICs) that perform equivalent functions. The design applies to any such IC in which output signal charges from the pixels in a given row are transferred simultaneously into sampling capacitors at the bottoms of the columns, then voltages representing individual pixel charges are read out in sequence by sequentially turning on column-selecting field-effect transistors (FETs) in synchronism with source-follower- or operational-amplifier-based amplifier circuits. The improved design affords the best features of prior source-follower-and operational- amplifier-based designs while overcoming the major limitations of those designs. The limitations can be summarized as follows: a) For a source-follower-based signal chain, the ohmic voltage drop associated with DC bias current flowing through the column-selection FET causes unacceptable voltage offset, nonlinearity, and reduced small-signal gain. b) For an operational-amplifier-based signal chain, the required bias current and the output noise increase superlinearly with size of the pixel array because of a corresponding increase in the effective capacitance of the row bus used to couple the sampled column charges to the operational amplifier. The effect of the bus capacitance is to simultaneously slow down the readout circuit and increase noise through the Miller effect.

Pain, Bedabrata↗

Customizable Digital Receivers for Radar

Compact, highly customizable digital receivers are being developed for the system described in 'Radar Interferometer for Topographic Mapping of Glaciers and Ice Sheets' (NPO-43962), NASA Tech Briefs, Vol. 31, No. 7 (August 2007), page 72. The receivers are required to operate in unison, sampling radar returns received by the antenna elements in a digital beam-forming (DBF) mode. The design of these receivers could also be adapted to commercial radar systems. At the time of reporting the information for this article, there were no commercially available digital receivers capable of satisfying all of the operational requirements and compact enough to be mounted directly on the antenna elements. A provided figure depicts the overall system of which the digital receivers are parts. Each digital receiver includes an analog-to-digital converter (ADC), a demultiplexer (DMUX), and a field-programmable gate array (FPGA). The ADC effects 10-bit band-pass sampling of input signals having frequencies up to 3.5 GHz. The input samples are demultiplexed at a user-selectable rate of 1:2 or 1:4, then buffered in part of the FPGA that functions as a first-in/first-out (FIFO) memory. Another part of the FPGA serves as a controller for the ADC, DMUX, and FIFO memory and as an interface between (1) the rest of the receiver and (2) a front-panel data port (FPDP) bus, which is an industry-standard parallel data bus that has a high data-rate capability and multichannel configuration suitable for DBF. Still other parts of the FPGA in each receiver perform signal-processing functions. The digital receivers can be configured to operate in a stand-alone mode, or in a multichannel mode as needed for DBF. The customizability of the receiver makes it applicable to a broad range of system architectures. The capability for operation of receivers in either a stand-alone or a DBF mode enables the use of the receivers in an unprecedentedly wide variety of radar systems.

Moller, Delwyn↗

Initial Performance Results on IBM POWER6

The POWER5+ processor has a faster memory bus than that of the previous generation POWER5 processor (533 MHz vs. 400 MHz), but the measured per-core memory bandwidth of the latter is better than that of the former (5.7 GB/s vs. 4.3 GB/s). The reason for this is that in the POWER5+, the two cores on the chip share the L2 cache, L3 cache and memory bus. The memory controller is also on the chip and is shared by the two cores. This serializes the path to memory. For consistently good performance on a wide range of applications, the performance of the processor, the memory subsystem, and the interconnects (both latency and bandwidth) should be balanced. Recognizing this, IBM has designed the Power6 processor so as to avoid the bottlenecks due to the L2 cache, memory controller and buffer chips of the POWER5+. Unlike the POWER5+, each core in the POWER6 has its own L2 cache (4 MB - double that of the Power5+), memory controller and buffer chips. Each core in the POWER6 runs at 4.7 GHz instead of 1.9 GHz in POWER5+. In this paper, we evaluate the performance of a dual-core Power6 based IBM p6-570 system, and we compare its performance with that of a dual-core Power5+ based IBM p575+ system. In this evaluation, we have used the High- Performance Computing Challenge (HPCC) benchmarks, NAS Parallel Benchmarks (NPB), and four real-world applications--three from computational fluid dynamics and one from climate modeling.

Saini, Subbash↗

Problems Encountered During the Recertification of the GLORY Solar Array Dual Axis Gimbal Drive Actuators

The Glory observatory is the current incarnation of the Vegetation Canopy Lidar (VCL) mission spacecraft bus. The VCL spacecraft bus, having been cancelled for programmatic reasons in 2000, was nearly integrated when it was put into storage for possible future use. The Glory mission was a suitable candidate for using this spacecraft and in 2006 an effort to recertify the two axis solar array gimbal drive after its extended storage was begun. What was expected to be a simple performance validation of the two dual axis gimbal stepper motors became a serious test, diagnosis and repair task once questions arose on the flight worthiness of the hardware. A significant test program logic flow was developed which identified decisions that could be made based on the results of individual recertification tests. Without disassembling the bi-axial gimbals, beginning with stepper motor threshold voltage measurements and relating these to powered drive torque measurements, both performed at the spacecraft integrator s facility, a confusing picture of the health of the actuators came to light. Tests at the gimbal assembly level and tests of the disassembled actuators were performed by the manufacturer to validate our results and torque discrepancies were noted. Further disassembly to the component level of the actuator revealed the source of the torque loss.

Saltzman, Marc↗