Search NASASearch

Engineering topics

Schnurr, Richard

Publications and source records attributed to Schnurr, Richard.

GOES-16 Magnetometers Anomaly Solar-Angle Based Characterization and Correction

GOES-R launched aboard an Atlas V 541 rocket from Space Launch Complex-41 at Cape Canaveral Air Force Station, Florida, on November 19, 2016. The first satellite in the series, GOES-R, was renamed GOES-16 upon reaching geostationary orbit GOES-16 at GOES-Checkout location (89.5 degrees West Longitude) during PLT (Post-Launch Testing). The GOES-16 magnetometer boom was deployed on December 7, 2016 and magnetometer checkout began. GOES-16 replaced GOES-13 as NOAA's operational GOES-East satellite on December 18, 2017. The GOES-16 satellite operational location (GOES-East) is at 75.2 degrees West Longitude.

Magnetometers

JWST Near-Infrared Detectors: Latest Test Results

The James Webb Space Telescope, an infrared-optimized space telescope being developed by NASA for launch in 2013, will utilize cutting-edge detector technology in its investigation of fundamental questions in astrophysics. JWST's near infrared spectrograph, NIRSpec utilizes two 2048 x 2048 HdCdTe arrays with Sidecar ASIC readout electronics developed by Teledyne to provide spectral coverage from 0.6 microns to 5 microns. We present recent test and calibration results for the NIRSpec flight arrays as well as data processing routines for noise reduction and cosmic ray rejection.

Smith, Erin C.

BAE Systems Radiation Hardened SpaceWire ASIC and Roadmap

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 ASlC is comprised entirely of reusable core elements, many of which are already flight-proven. It incorporates a 4-port SpaceWire router with two local ports, dual PC1 bus interfaces, a microcontroller, 32KB of internal memory, -and a memory controller for additional external memory use. The SpaceWire ASlC is planned for use on both the Geostationary Operational Environmental Satellites (GOES)-R and the Lunar Reconnaissance Orbiter (LRO). Engineering parts have already been delivered to both programs. This paper discusses the SpaceWire protocol and those elements of it that have been built into the current SpaceWire reusable core. There are features within the core that go beyond the current standard that can be enabled or disabled by the user and these will be described. The adaptation of SpaceWire to BAE Systems' On Chip Bus (OCB) for compatibility with the other reusable cores will be discussed. Optional configurations within user systems will be shown. The physical imp!ementation of the design will be described and test results from the hardware will be discussed. Finally, the BAE Systems roadmap for SpaceWire developments will be discussed, including some products already in design as well as longer term plans.

Berger, Richard

SpaceWire Protocol ID: What Does It Mean To You?

Spacewire is becoming a popular solution for satellite high-speed data buses because it is a simple standard that provides great flexibility for a wide range of system requirements. It is simple in packet format and protocol, allowing users to easily tailor their implementation for their specific application. Some of the attractive aspects of Spacewire that make it easy to implement also make it hard for future reuse. Protocol reuse is difficult because Spacewire does not have a defined mechanism to communicate with the higher layers of the protocol stack. This has forced users of Spacewire to define unique packet formats and define how these packets are to be processed. Each mission writes their own Interface Control Document (ICD) and tailors Spacewire for their specific requirements making reuse difficult. Part of the reason for this habit may be because engineers typically optimize designs for their own requirements in the absence of a standard. This is an inefficient use of project resources and costs more to develop missions. A new packet format for Spacewire has been defined as a solution for this problem. This new packet format is a compliment to the Spacewire standard that will support protocol development upon Spacewire. The new packet definition does not replace the current packet structure, i.e., does not make the standard obsolete, but merely extends the standard for those who want to develop protocols over Spacewire. The Spacewire packet is defined with the first part being the Destination Address, which may be one or more bytes. This is followed by the packet cargo, which is user defined. The cargo is truncated with an End-Of-Packet (EOP) marker. This packet structure offers low packet overhead and allows the user to define how the contents are to be formatted. It also provides for many different addressing schemes, which provide flexibility in the system. This packet flexibility is typically an attractive part of the Spacewire. The new extended packet format adds one new field to the packet that greatly enhances the capability of Spacewire. This new field called the Protocol Identifier (ID) is used to identify the packet contents and the associated processing for the packet. This feature along with the restriction in the packet format that uses the Protocol ID, allows a deterministic method of decoding packets that was not before possible. The first part of the packet is still the Destination Address, which still conforms to the original standard but with one restriction. The restriction is that the first byte seen at the destination by the user needs to be a logical address, independent of the addressing scheme used. The second field is defined as the Protocol ID, which is usually one byte in length. The packet cargo (user defined) follows the Protocol ID. After the packet cargo is the EOP, which defines the end of packet. The value of the Protocol ID is assigned by the Spacewire working group and the protocol description published for others to use. The development of Protocols for Spacewire is currently the area of greatest activity by the Spacewire working group. The first protocol definition by the working group has been completed and is now in the process of formal standardization. There are many other protocols in development for missions that have not yet received formal Protocol ID assignment, but even if the protocols are not formally assigned a value, this effort will provide synergism for future developments.

Rakow, Glenn

SpaceWire Protocol ID: What Does it Mean to You?

This document is a slide presentation reviewing the SpaceWire (SW) Protocol. The purpose of the presentation is to describe the latest work of the SW working group to promote upper level protocol standardization. The presentation also briefly describes the SW protocol.

Rakow, Glenn Parker

Space Wire Upper Layer Protocols

This viewgraph presentation addresses efforts to provide a streamlined approach for developing SpaceWire Upper layer protocols which allows industry to drive standardized communication solutions for real projects. The presentation proposes a simple packet header that will allow flexibility in implementing a diverse range of protocols.

Rakow, Glenn

Standard Spacecraft Interfaces and IP Network Architectures: Prototyping Activities at the GSFC

Advancements in fright semiconductor technology have opened the door for IP-based networking in spacecraft architectures. The GSFC believes the same signlJicant cost savings gained using MIL-STD-1553/1773 as a standard low rate interface for spacecraft busses cun be realized for highspeed network interfaces. To that end, GSFC is developing hardware and software to support a seamless, space mission IP network based on Ethernet and MIL-STD-1553. The Ethernet network shall connect all fright computers and communications systems using interface standards defined by the CCSDS Standard Onboard InterFace (SOIF) Panel. This paper shall discuss the prototyping effort underway at GSFC and expected results.

Schnurr, Richard

Reliable Transport over SpaceWire for James Webb Space Telescope (JWST) Focal Plane Electronics (FPE) Network

NASA's James Webb Space Telescope (JWST) faces difficult technical and budgetary challenges to overcome before it is scheduled launch in 2010. The Integrated Science Instrument Module (ISIM), shares these challenges. The major challenge addressed in this paper is the data network used to collect, process, compresses and store Infrared data. A total of 114 Mbps of raw information must be collected from 19 sources and delivered to the two redundant data processing units across a twenty meter deployed thermally restricted interface. Further data must be transferred to the solid-state recorder and the spacecraft. The JWST detectors are kept at cryogenic temperatures to obtain the sensitivity necessary to measure faint energy sources. The Focal Plane Electronics (FPE) that sample the detector, generate packets from the samples, and transmit these packets to the processing electronics must dissipate little power in order to help keep the detectors at these cold temperatures. Separating the low powered front-end electronics from the higher-powered processing electronics, and using a simple high-speed protocol to transmit the detector data minimize the power dissipation near the detectors. Low Voltage Differential Signaling (LVDS) drivers were considered an obvious choice for physical layer because of their high speed and low power. The mechanical restriction on the number cables across the thermal interface force the Image packets to be concentrated upon two high-speed links. These links connect the many image packet sources, Focal Plane Electronics (FPE), located near the cryogenic detectors to the processing electronics on the spacecraft structure. From 12 to 10,000 seconds of raw data are processed to make up an image, various algorithms integrate the pixel data Loss of commands to configure the detectors as well as the loss of science data itself may cause inefficiency in the use of the telescope that are unacceptable given the high cost of the observatory. This combination of requirements necessitates a redundant, fault tolerant, high- speed, low mass, low power network with a low Bit error Rate(1E-9- 1E-12). The ISIM systems team performed many studies of the various network architectures that meeting these requirements. The architecture selected uses the Spacewire protocol, with the addition of a new transport and network layer added to implement end-to-end reliable transport. The network and reliable transport mechanism must be implemented in hardware because of the high average information rate and the restriction on the ability of the detectors to buffer data due to power and size restrictions. This network and transport mechanism was designed to be compatible with existing Spacewire links and routers so that existing equipment and designs may be leveraged upon. The transport layer specification is being coordinated with European Space Agency (ESA), Spacewire Working Group and the Consultative Committee for Space Data System (CCSDS) PlK Standard Onboard Interface (SOIF) panel, with the intent of developing a standard for reliable transport for Spacewire. Changes to the protocol presented are likely since negotiations are ongoing with these groups. A block of RTL VHDL that implements a multi-port Spacewire router with an external user interface will be developed and integrated with an existing Spacewire Link design. The external user interface will be the local interface that sources and sinks packets onto and off of the network (Figure 3). The external user interface implements the network and transport layer and handles acknowledgements and re-tries of packets for reliable transport over the network. Because the design is written in RTL, it may be ported to any technology but will initially be targeted to the new Actel Accelerator series (AX) part. Each link will run at 160 Mbps and the power will be about 0.165 Watt per link worst case in the Actel AX.

Rakow, Glenn

Test and validation for robot arm control dynamics simulation

The Flight Telerobotic Servicer (FTS) program will require an ability to develop, in a cost effective manner, many simulation models for design, analysis, performance evaluation, and crew training. Computational speed and the degree of modeling fidelity associated with each simulation must be commensurate with problem objectives. To demonstrate evolving state-of-the-art general purpose multibody modeling capabilities, to validate these by laboratory testing, and to expose their modeling shortcomings, two focus problems at the opposite ends of the simulation spectrum are defined: (1) Coarse Acquisition Control Dynamics. Create a real time man-in-the-control-loop simulator. Provide animated graphical display of robot arm dynamics and tactile feedback sufficient for cueing the operator. Interface simulator software with human operated tactile feedback controller; i.e., the Kraft mini-master. (2) Fine, Precision Mode Control Dynamics. Create a high speed, high fidelity simulation model for the design, analysis, and performance evaluation of autonomous 7 degree-of-freedom (DOF) trajectory control algorithms. This model must contain detail dynamic models for all significant dynamics elements within the robot arm, such as joint drive mechanisms.

Yae, K. Harold