Search NASA⌕ Search

Engineering topics

Rakow, Glenn

Publications and source records attributed to Rakow, Glenn.

At least 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2016

New Approaches for Direct Current (DC) Balanced SpaceWire

Direct Current (DC) line balanced SpaceWire is attractive for a number of reasons. Firstly, a DC line balanced interface provides the ability to isolate the physical layer with either a transformer or capacitor to achieve higher common mode voltage rejection and or the complete galvanic isolation in the case of a transformer. And secondly, it provides the possibility to reduce the number of conductors and transceivers in the classical SpaceWire interface by half by eliminating the Strobe line. Depending on the modulator scheme the clock data recovery frequency requirements may be only twice that of the transmit clock, or even match the transmit clock: depending on the Field Programmable Gate Array (FPGA) decoder design. In this paper, several different implementation scenarios will be discussed. Two of these scenarios are backward compatible with the existing SpaceWire hardware standards except for changes at the character level. Three other scenarios, while decreasing by half the standard SpaceWire hardware components, will require changes at both the character and signal levels and work with fixed rates. Other scenarios with variable data rates will require an additional SpaceWire interface handshake initialization sequence.

Line encoding↗
NASA NTRS2016

New Approaches for DC Balanced SpaceWire

Direct Current (DC) line balanced SpaceWire is attractive for a number of reasons. Firstly, a DC line balanced interface provides the ability to isolate the physical layer with either a transformer or capacitor to achieve higher common mode voltage rejection and/or the complete galvanic isolation in the case of a transformer. Secondly, it provides the possibility to reduce the number of conductors and transceivers in the classical SpaceWire interface by half by eliminating the Strobe line. Depending on the modulator scheme - the clock data recovery frequency requirements may be only twice that of the transmit clock, or even match the transmit clock: depending on the Field Programmable Gate Array (FPGA) decoder design. In this paper, several different implementation scenarios will be discussed. Two of these scenarios are backward compatible with the existing SpaceWire hardware standards except for changes at the character level. Three other scenarios, while decreasing by half the standard SpaceWire hardware components, will require changes at both the character and signal levels and work with fixed rates. Other scenarios with variable data rates will require an additional SpaceWire interface handshake initialization sequence.

SpaceWire↗
NASA NTRS2016

Human Mars Lander Design for NASA's Evolvable Mars Campaign

Landing humans on Mars will require entry, descent, and landing capability beyond the current state of the art. Nearly twenty times more delivered payload and an order of magnitude improvement in precision landing capability will be necessary. To better assess entry, descent, and landing technology options and sensitivities to future human mission design variations, a series of design studies on human-class Mars landers has been initiated. This paper describes the results of the first design study in the series of studies to be completed in 2016 and includes configuration, trajectory and subsystem design details for a lander with Hypersonic Inflatable Aerodynamic Decelerator (HIAD) entry technology. Future design activities in this series will focus on other entry technology options.

Polsgrove, Tara↗
NASA NTRS2014

Manchester Coding Option for SpaceWire: Providing Choices for System Level Design

This paper proposes an optional coding scheme for SpaceWire in lieu of the current Data Strobe scheme for three reasons. First reason is to provide a straightforward method for electrical isolation of the interface; secondly to provide ability to reduce the mass and bend radius of the SpaceWire cable; and thirdly to provide a means for a common physical layer over which multiple spacecraft onboard data link protocols could operate for a wide range of data rates. The intent is to accomplish these goals without significant change to existing SpaceWire design investments. The ability to optionally use Manchester coding in place of the current Data Strobe coding provides the ability to DC balanced the signal transitions unlike the SpaceWire Data Strobe coding; and therefore the ability to isolate the electrical interface without concern. Additionally, because the Manchester code has the clock and data encoded on the same signal, the number of wires of the existing SpaceWire cable could be optionally reduced by 50. This reduction could be an important consideration for many users of SpaceWire as indicated by the already existing effort underway by the SpaceWire working group to reduce the cable mass and bend radius by elimination of shields. However, reducing the signal count by half would provide even greater gains. It is proposed to restrict the data rate for the optional Manchester coding to a fixed data rate of 10 Megabits per second (Mbps) in order to make the necessary changes simple and still able to run in current radiation tolerant Field Programmable Gate Arrays (FPGAs). Even with this constraint, 10 Mbps will meet many applications where SpaceWire is used. These include command and control applications and many instruments applications with have moderate data rate. For most NASA flight implementations, SpaceWire designs are in rad-tolerant FPGAs, and the desire to preserve the heritage design investment is important for cost and risk considerations. The Manchester coding option can be accommodated in existing designs with only changes to the FPGA.

Electrical Isolation↗
NASA NTRS2008

NASA Activities: SpaceWire Working Group Meeting

This brief presentation highlights the efforts of the SpaceWire working group. The European Space Agency (ESA) contracted with the University of Dundee (UoD) to develop a prototype SpaceFibre Codec, which UoD has been demonstrated in hardware. UoD released a SpaceFibre Outline Specification which NASA plans to evaluate using a SpaceFibre sub-orbital demonstration (in development). Comments, questions and recommendations for ESA and UoD are provided here to generate discussion and expand participation. General findings are that the system level behavior of SpaceFibre is missing from the SpaceFibre Outline Specification, there is a need to understand how SpaceWire maps to SpaceFibre (and vice versa), and there is a need to clarify user interface to resolve inconsistencies. Architecture, virtual channel and programmatic recommendations are presented.

Rakow, Glenn↗
NASA NTRS2007

SpaceFibre Discussion

This viewgraph presentation discusses the future use of SpaceFibre, a high speed optical extension to the SpaceWire, for NASA and DOD missions. NASA, and US industries would like to work with the European developers currently working on this standard.

Rakow, Glenn↗
NASA NTRS2007

Magnetospheric Multiscale Mission SpaceWire Implementation

This viewgraph presentation reviews the use of SpaceWire in the Magnetospheric Multiscale Mission (MMS). The Science Objectives of the are to Discover the fundamental plasma physics process of reconnection in the Earth's magnetosphere using temporal scales of milliseconds to seconds and spatial scales of 10s to 100s of km. MMS should be the first NASA mission to fly several new Spacewire protocols including: - Remote Memory Access Protocol - Distributed interrupt Protocol - Standardized Backplane These are briefly reviewed in the presentation.

Jackson, George↗
NASA NTRS2007

SpaceWire Plug and Play Updates

This viewgraph presentation reviews the work of the SpaceWire Plug N Play Workgroup. (SpW PnP WG). The chief product of SpW PnP WG will be to develop specification of necessary hardware features required in support upper layer (software) PnP implementations.

Rakow, Glenn↗
NASA NTRS2006

SpaceWire Plug and Play

The ability to rapidly deploy inexpensive satellites to meet tactical goals has become an important goal for military space systems. In fact, Operationally Responsive Space (ORS) has been in the spotlight at the highest levels. The Office of the Secretary of Defense (OSD) has identified that the critical next step is developing the bus standards and modular interfaces. Historically, satellite components have been constructed based on bus standards and standardized interfaces. However, this has not been done to a degree, which would allow the rapid deployment of a satellite. Advancements in plug-and-play (PnP) technologies for terrestrial applications can serve as a baseline model for a PnP approach for satellite applications. Since SpaceWire (SpW) has become a de facto standard for satellite high-speed (greater than 200Mbp) on-board communications, it has become important for SpW to adapt to this Plug and Play (PnP) environment. Because SpW is simply a bulk transport protocol and lacks built-in PnP features, several changes are required to facilitate PnP with SpW. The first is for Host(s) to figure out what the network looks like, i.e., how pieces of the network, routers and nodes, are connected together; network mapping, and to receive notice of changes to the network. The second is for the components connected to the network to be understood so that they can communicate. The first element, network topology mapping & change of status indication, is being defined (topic of this paper). The second element describing how components are to communicate has been defined by ARFL with the electronic data sheets known as XTEDS. The first element, network mapping, is recent activities performed by Air Force Research Lab (ARFL), Naval Research Lab (NRL), NASA and US industry (Honeywell, Clearwater, FL, and others). This work has resulted in the development of a protocol that will perform the lower level functions of network mapping and Change Of Status (COS) indication required by Plug 'n' Play over SpaceWire. This work will be presented to the SpaceWire working group for standardization under European Cooperation for Space Standardization (ECSS) and to obtain a permanent Protocol ID (see SpaceWire Protocol ID: What Does it Mean to You; IEEE Aerospace Conference 2006). The portion of the Plug 'n' Play protocol that will be described in this paper is how the Host(s) of a SpaceWire network map the network and detect additions and deletions of devices on a SpaceWire network.

Rakow, Glenn↗
NASA NTRS2006

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↗
NASA NTRS2006

NASA SpaceWire Activities/Comments/Recommendations

This viewgraph presentation reviews NASA's activities, and proposes recommendations for the further use of the SpaceWire (SpW). The areas covered in this presentation are: (1) Protocol ID assignment, (2) Protocol development, (3) Plug & Play (PnP), (4) Recommended additions t o SpW protocol and (5) SpaceFibre trade.

Rakow, Glenn↗
NASA NTRS2006

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↗