Search NASA⌕ Search

SEARCH · Search NASA

Results for “Space Network Time Synchronization”

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.

105 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS2014

Space Link Extension Protocol Emulation for High-Throughput, High-Latency Network Connections

New space missions require higher data rates and new protocols to meet these requirements. These high data rate space communication links push the limitations of not only the space communication links, but of the ground communication networks and protocols which forward user data to remote ground stations (GS) for transmission. The Consultative Committee for Space Data Systems, (CCSDS) Space Link Extension (SLE) standard protocol is one protocol that has been proposed for use by the NASA Space Network (SN) Ground Segment Sustainment (SGSS) program. New protocol implementations must be carefully tested to ensure that they provide the required functionality, especially because of the remote nature of spacecraft. The SLE protocol standard has been tested in the NASA Glenn Research Center's SCENIC Emulation Lab in order to observe its operation under realistic network delay conditions. More specifically, the delay between then NASA Integrated Services Network (NISN) and spacecraft has been emulated. The round trip time (RTT) delay for the continental NISN network has been shown to be up to 120ms; as such the SLE protocol was tested with network delays ranging from 0ms to 200ms. Both a base network condition and an SLE connection were tested with these RTT delays, and the reaction of both network tests to the delay conditions were recorded. Throughput for both of these links was set at 1.2Gbps. The results will show that, in the presence of realistic network delay, the SLE link throughput is significantly reduced while the base network throughput however remained at the 1.2Gbps specification. The decrease in SLE throughput has been attributed to the implementation's use of blocking calls. The decrease in throughput is not acceptable for high data rate links, as the link requires constant data a flow in order for spacecraft and ground radios to stay synchronized, unless significant data is queued a the ground station. In cases where queuing the data is not an option, such as during real time transmissions, the SLE implementation cannot support high data rate communication.

Computer Networking↗
NASA NTRSDate not supplied

International Coordination and Cooperation on LunaNet Spectrum

LunaNet is planned to be the network of networks operated by a set of cooperating organizations to provide interoperable Communications, networking, Position, Navigation, and Timing (CPNT) services to users on and around the Moon based on a framework of mutually agreed-upon standards, protocols, frequency bands and interface requirements. LunaNet follows a service-oriented architecture that is agnostic about the types of organizations that provide services, e.g., government, industry, or academia. LunaNet is open, scalable, resilient, secure, and extensible. To achieve these goals, LunaNet Service Providers (LNSP) must coordinate with each other to define and develop the architecture, to plan initial and evolved capabilities, and to operate their networks. One of the central LunaNet tenets is the use of shared spectrum. For example, the Lunar Augmented Navigation Service (LANS) acts like a Global Navigation Satellite System (GNSS) such as the US Global Positioning System (GPS) or European Galileo but the LNSPs’ contributions to LunaNet must use the same frequency band (2483.5 MHz-2500.0 MHz) and transmit the same waveform synchronized by highly accurate clocks so that Users ‘see’ one virtual network and use the same multilateration algorithm to determine their positions. This necessitates a high degree of spectrum coordination. NASA’s Lunar and Human Spaceflight Spectrum Management Team has been actively supporting development of the LunaNet Interoperability Specification (LNIS), soliciting inputs from spectrum policy and planning experts across NASA, ESA and JAXA. Cislunar spectrum use considerations have been studied and adjudicated within the Space Frequency Coordination Group (SFCG) and inform the ongoing discussion of a lunar communication and navigation architecture within the existing radio regulatory framework of the International Telecommunication Union, leading to the 2027 World Radiocommunication Conference (WRC-27). The frequency plan contained in the publicly released draft of the LunaNet Interoperability Specification reflects the initial phase of exploration (roughly to 2030) defining an optimal set of radio frequencies in appropriately allocated services consistent with WRC-23 decisions for use by known or planned CPNT applications, while striving to maximize coexistence and compatibility amongst cislunar systems and other systems within the near-Earth regime (< 2 million km from Earth). Important considerations include: protection of extremely sensitive receive-only radio astronomy systems on the lunar far side, known as the Shielded Zone of the Moon (SZM); compatibility between Direct with Earth (DWE) communications links and links needed to support relay satellites in lunar orbit with their customer systems on orbit or on the lunar surface; compatibility between multiple lunar surface communications systems and capabilities over varied and challenging terrain and distances; as well as ensuring compatibility and interoperability between navigation systems which either leverage Earth-based or in-situ lunar systems. In addition, the lunar CPNT architecture is envisioned to be the basis – with adjustments – of the future Mars CPNT architecture as we expand into the solar system using Interplanetary Networking (IPN). The second phase of lunar spectrum definition will address planned international capabilities for the next decade that will require action at WRC-27 and beyond. This paper will discuss each of these considerations in more depth and how the current LunaNet frequency plan addresses them.

LunaNet↗
NASA NTRS2017

A Trilateration Scheme for Relative Positioning

We introduce a trilateration scheme that evaluates the 3-dimensional (3-D) relative position between a reference spacecraft and a target spacecraft using raw-range measurements from a distance baseline of known locations, which we call “anchors”. The anchors can be antennas of a ground-based network (e.g., Deep Space Network (DSN) or Near Earth Network (NEN) stations), or satellites of a spacebased network (e.g., global positioning system (GPS) or tracking and data relay satellite (TDRS)). We define raw-range as the range that includes all the systematic errors that occur during range measurements. A unique feature of this approach is that accurate relative position is derived from a “differencing function” of raw-range measurements of the reference spacecraft and target spacecraft, thereby eliminating most of the systematic errors, such as media effects, ephemeris errors, instrument delays, clock bias, etc. There can be an arbitrary number of target spacecraft, and relative positioning of target spacecraft with respect to the reference spacecraft can be done simultaneously. In this paper, we first assume an idealized system in which clocks on the reference and target spacecraft are synchronized, with clocks of the anchors synchronized as well. We develop a novel iterative algorithm that computes the relative position of the target spacecraft with respect to the reference spacecraft. We illustrate the relative positioning method using the scenario of a network of three ground stations (i.e., the anchors) at Goldstone, California, USA, Madrid, Spain, and Marlargue, Argentina tracking two spacecraft at geosynchronous orbit distance. We demonstrate that the algorithm converges to submeter accuracy in estimating the relative position, in the presence of random errors and systematic errors in raw-range measurements, and in the presence of angular errors in estimating the pointing vectors between the anchors and the reference spacecraft. Next, we relax the requirement of perfect time synchronization between spacecraft, and show that by using an additional anchor, one can estimate and remove the clock biases between the reference and target spacecraft. We add a ground station at Kourou to the above example of three ground stations of Goldstone, Madrid, and Marlargue, and demonstrate that the updated algorithm also converges to meter-level accuracy (submeter in some cases) in the presence of clock biases in addition to the random errors, systematic errors, and angular errors as shown in the above case. We compare this scheme with a similar trilateration scheme for relative positioning scheme first proposed by Montenbruck in 2002.

Cheung, Kar-Ming↗
NASA NTRS2012

SpaceCube Mini

This version of the SpaceCube will be a full-fledged, onboard space processing system capable of 2500+ MIPS, and featuring a number of plug-andplay gigabit and standard interfaces, all in a condensed 3x3x3 form factor [less than 10 watts and less than 3 lb (approximately equal to 1.4 kg)]. The main processing engine is the Xilinx SIRF radiation- hardened-by-design Virtex-5 FX-130T field-programmable gate array (FPGA). Even as the SpaceCube 2.0 version (currently under test) is being targeted as the platform of choice for a number of the upcoming Earth Science Decadal Survey missions, GSFC has been contacted by customers who wish to see a system that incorporates key features of the version 2.0 architecture in an even smaller form factor. In order to fulfill that need, the SpaceCube Mini is being designed, and will be a very compact and low-power system. A similar flight system with this combination of small size, low power, low cost, adaptability, and extremely high processing power does not otherwise exist, and the SpaceCube Mini will be of tremendous benefit to GSFC and its partners. The SpaceCube Mini will utilize space-grade components. The primary processing engine of the Mini is the Xilinx Virtex-5 SIRF FX-130T radiation-hardened-by-design FPGA for critical flight applications in high-radiation environments. The Mini can also be equipped with a commercial Xilinx Virtex-5 FPGA with integrated PowerPCs for a low-cost, high-power computing platform for use in the relatively radiation- benign LEOs (low-Earth orbits). In either case, this version of the Space-Cube will weigh less than 3 pounds (.1.4 kg), conform to the CubeSat form-factor (10x10x10 cm), and will be low power (less than 10 watts for typical applications). The SpaceCube Mini will have a radiation-hardened Aeroflex FPGA for configuring and scrubbing the Xilinx FPGA by utilizing the onboard FLASH memory to store the configuration files. The FLASH memory will also be used for storing algorithm and application code for the PowerPCs and the Xilinx FPGA. In addition, it will feature highspeed DDR SDRAM (double data rate synchronous dynamic random-access memory) to store the instructions and data of active applications. This version will also feature SATA-II and Gigabit Ethernet interfaces. Furthermore, there will also be general-purpose, multi-gigabit interfaces. In addition, the system will have dozens of transceivers that can support LVDS (low-voltage differential signaling), RS-422, or SpaceWire. The SpaceCube Mini includes an I/O card that can be customized to meet the needs of each mission. This version of the SpaceCube will be designed so that multiple Minis can be networked together using SpaceWire, Ethernet, or even a custom protocol. Scalability can be provided by networking multiple SpaceCube Minis together. Rigid-Flex technology is being targeted for the construction of the SpaceCube Mini, which will make the extremely compact and low-weight design feasible. The SpaceCube Mini is designed to fit in the compact CubeSat form factor, thus allowing deployment in a new class of missions that the previous SpaceCube versions were not suited for. At the time of this reporting, engineering units should be available in the summer 2012.

Michael Lin↗
NASA NTRS2009

FPGA-Based Networked Phasemeter for a Heterodyne Interferometer

A document discusses a component of a laser metrology system designed to measure displacements along the line of sight with precision on the order of a tenth the diameter of an atom. This component, the phasemeter, measures the relative phase of two electrical signals and transfers that information to a computer. Because the metrology system measures the differences between two optical paths, the phasemeter has two inputs, called measure and reference. The reference signal is nominally a perfect square wave with a 50- percent duty cycle (though only rising edges are used). As the metrology system detects motion, the difference between the reference and measure signal phases is proportional to the displacement of the motion. The phasemeter, therefore, counts the elapsed time between rising edges in the two signals, and converts the time into an estimate of phase delay. The hardware consists of a circuit board that plugs into a COTS (commercial, off-the- shelf) Spartan-III FPGA (field-programmable gate array) evaluation board. It has two BNC inputs, (reference and measure), a CMOS logic chip to buffer the inputs, and an Ethernet jack for transmitting reduced-data to a PC. Two extra BNC connectors can be attached for future expandability, such as external synchronization. Each phasemeter handles one metrology channel. A bank of six phasemeters (and two zero-crossing detector cards) with an Ethernet switch can monitor the rigid body motion of an object. This device is smaller and cheaper than existing zero-crossing phasemeters. Also, because it uses Ethernet for communication with a computer, instead of a VME bridge, it is much easier to use. The phasemeter is a key part of the Precision Deployable Apertures and Structures strategic R&D effort to design large, deployable, segmented space telescopes.

Rao, Shanti↗
NASA NTRS2018

Using the cFS Command and Data Dictionary (CCDD) to Automate Software Development on Habulous

Final paper is attached. The NASA developed Core Flight System (cFS) is a reusable software architecture that has been used on multiple spaceflight missions. By using this framework, missions are able to reuse code from other missions, as well as leverage deployment onto similar computer architectures (i.e. not "reinvent the wheel" on each new mission). The success in the cFS concept can be seen in the large number of projects using cFS at FSW-2018. The Habulous project is an Earth-based testbed, used for hardware and software that may one day be used on a future space habitat unit, with many participating groups from various NASA centers and aerospace organizations around the country. The distributed nature of the various teams mean that defining (and following) an interface definition is critical on the project. Additionally, since various groups use various types of computer hardware (32/64-bit, big/little endian, Linux/VxWorks/Windows) many additional complications exist in interfacing all the various components into a final integrated system. cFS is used on the majority the flight software (FSW) in running in Habulous. But some subsystems have elected to not use cFS, and use a software bridge (called SBN_lib) to interact with the other cFS nodes in Habulous. In order to most efficiently develop the FSW, a central database is used to define and store each message sent by cFS. A Command and Data Dictionary (CDD) is something nearly universal on spacecraft, but as a team we worked to develop the CDD before the SW development was complete, and not treat it like "as built" documentation. To manage the CDD, the cFS Command and Data Dictionary (CCDD) tool was chosen (available from NASA as open source software). The CCDD tool has successfully been used to automate/autocode a large amount of software used on Habulous, as we are hoping to use it to define even more items in the future (time-triggered Ethernet (TTE) network maps, CPU scheduling). Additionally, Habulous has been exploring the use of cFS on wildly heterogeneous CPUs, and how to coordinate all those various machines using/extending the software bus – network (SBN) application in cFS, as well as TTE to coordinate message passing between various synchronized machines. The major topics to be covered in the presentation are: (1) Updating to the CCSDS_v2 extended headers (and using CPU# as subsystem ID). (2) Managing all the message identification numbers for each cFS message sent/received on any of the various CPUs. (3) Using the CCDD information to automatically generate the C-header files that define the structure for all software bus (SB) commands/telemetry messages. (4) Using the CCDD to automatically generate XML Telemetry and Command Exchange (XTCE) files, which streams display production/integration/testing in a web based display architecture (5) Extending/customizing SBN to pass messages among computers on multiple networks. (6) Using "Protobetter" inside SBN to manage different endian-ness/architectures. (7) Using SBN_lib to allow non-cFS node to communicate with cFS nodes. (8) Developing TTE network and schedule tables for all the various CPUs to use.

Hirsh, Robert L.↗
NASA NTRSDate not supplied

Open Data Integration (ODIN): A Concurrent, Distributed Message-Based Architecture and Framework for Disaster Response

The Runtime for Airspace Concept Evaluation (RACE) is an open-source software architecture and framework to build configurable, highly concurrent and distributed message-based systems that offer scalable, low-latency performance on commodity hardware. RACE was used in commercial aviation applications to rapidly build systems that span several machines (including synchronized displays), interface existing hardware simulators and other live data feeds, and incorporate sophisticated visualization components such as NASA WorldWind. These RACE applications validated elements of the FAA’s System Wide Information Management (SWIM) Program, handling up to 1000 messages/sec from diverse sources (SFDPS, TFM-DATA, TAIS, ASDE-X, ITWS and local ADS) for 4,500 simultaneous flights tracked in the next-generation air transportation system’s digital backbone. We have since generalized RACE to support Open Data Integration (ODIN) applications outside aviation. Systems built with RACE/ODIN can be deployed in the field, on commodity hardware, and operate with limited or intermittent connectivity to the outside world. Our primary use case is a web-server with local/persistent data storage that runs within and only serves the stakeholder network (e.g. an incident command post). We are tailoring the RACE/ODIN system to support wildland fire management for the upcoming NASA Wildland Fire Safety Demonstration Series. RACE-ODIN is under consideration for application in the Scalable Traffic Management for Emergency Response Operations project, or STEReO, which aims to create a system that can be deployed during emergencies, to coordinate multiple elements of disaster response. Such data sources predominantly come from existing services on the internet (e.g. weather and satellite data, imported from so called "edge servers") but can also include dynamic (real-time) data from computer simulations and within the stakeholder network (such as aircraft and personnel tracking information). We will present the architecture and ODIN system demonstration incorporating local data from instrumented power-line towers, interpolated weather data and geospatial data from space-based platforms.

Joseph C Coughlan↗
NASA NTRSDate not supplied

Open Data Integration (ODIN): A Concurrent, Distributed Message-Based Architecture and Framework for Disaster Response

The Runtime for Airspace Concept Evaluation (RACE) is an open-source software architecture and framework to build configurable, highly concurrent and distributed message-based systems that offer scalable, low-latency performance on commodity hardware. RACE was used in commercial aviation applications to rapidly build systems that span several machines (including synchronized displays), interface existing hardware simulators and other live data feeds, and incorporate sophisticated visualization components such as NASA WorldWind. These RACE applications validated elements of the FAA’s System Wide Information Management (SWIM) Program, handling up to 1000 messages/sec from diverse sources (SFDPS, TFM-DATA, TAIS, ASDE-X, ITWS and local ADS) for 4,500 simultaneous flights tracked in the next-generation air transportation system’s digital backbone. We have since generalized RACE to support Open Data Integration (ODIN) applications outside aviation. Systems built with RACE/ODIN can be deployed in the field, on commodity hardware, and operate with limited or intermittent connectivity to the outside world. Our primary use case is a web-server with local/persistent data storage that runs within and only serves the stakeholder network (e.g. an incident command post). We are tailoring the RACE/ODIN system to support wildland fire management for the upcoming NASA Wildland Fire Safety Demonstration Series. RACE-ODIN is under consideration for application in the Scalable Traffic Management for Emergency Response Operations project, or STEReO, which aims to create a system that can be deployed during emergencies, to coordinate multiple elements of disaster response. Such data sources predominantly come from existing services on the internet (e.g. weather and satellite data, imported from so called "edge servers") but can also include dynamic (real-time) data from computer simulations and within the stakeholder network (such as aircraft and personnel tracking information). We will present the architecture and ODIN system demonstration incorporating local data from instrumented power-line towers, interpolated weather data and geospatial data from space-based platforms.

Guillaume P Brat↗
NASA NTRSDate not supplied

The Design of a Flexible, Interoperable Navigation Signal for Future Lunar Missions

The LunaNet Interoperability Specification (LNIS) is a set of standards currently under development by NASA, ESA, and JAXA, which define a common, interoperable set of services and interfaces for lunar communication and navigation. The LNIS includes specifications for the GNSS-like Augmented Forward Signal (AFS). The LANS (Lunar Augmented Navigation Service) will be comprised of Multiple LunaNet Service Provider (LNSP) nodes broadcasting the AFS, such as NASA’s LCRNS (Lunar Communications Relay and Navigation Systems), ESA’s Moonlight LCNS (Lunar Communication and Navigation Services) and the Japan LNSS (Lunar Navigation Satellite System). The LANS will provide a GNSS-like capability enabling orbiting and surface users in lunar space (such as Artemis) to estimate their position, velocity and time as described in Giordano et al., (2023). Initial capabilities will focus on providing service to the lunar South pole region. The specification of AFS defines two orthogonal signal components on a single carrier, with the in-phase component (AFS-I) being a lower-chip-rate data channel tailored for applications where low SWaP is critical (e.g., IoT devices or search and rescue), and the quadrature component (AFS-Q) being a high-chip-rate data-less pilot signal for high-precision, robust lunar navigation and positioning applications. An initial description of AFS was provided in the LNIS, (2023), and initial analysis results were shown in Dafesh, et al., (2024). In this work, we provide rationale for updates to the LNIS that define key aspects of the signal including the primary spreading code designs for the data and pilot channels, and a three-tiered overlay code approach for the pilot channel that provides flexible signal acquisition alternatives, rapid time dissemination and robust frame Sync. The paper also describes a robust data sync word that is designed to enable frame Sync. for low-SWaP receivers that only use the I channel, as well as a low-density parity check code (LDPC) data message encoding design and interleaving definition. The work further describes the impact of the updated AFS design in terms of improved acquisition performance, interference resistance, navigation message capabilities and rapid absolute time dissemination for users able to access clock and ephemeris data over an external network. The cross-correlation and synchronization performance of the AFS design is also compared to potential alternatives, further providing rationale for the final signal design configuration.

LANS↗
NASA NTRS2025

The Design of a Flexible, Interoperable Navigation Signal for Future Lunar Missions

The LunaNet Interoperability Specification (LNIS) is a set of standards currently under development by NASA, ESA, and JAXA, which define a common, interoperable set of services and interfaces for lunar communication and navigation. The LNIS includes specifications for the GNSS-like Augmented Forward Signal (AFS). The LANS (Lunar Augmented Navigation Service) will be comprised of Multiple LunaNet Service Provider (LNSP) nodes broadcasting the AFS, such as NASA’s LCRNS (Lunar Communications Relay and Navigation Systems), ESA’s Moonlight LCNS (Lunar Communication and Navigation Services) and the Japan LNSS (Lunar Navigation Satellite System). The LANS will provide a GNSS-like capability enabling orbiting and surface users in lunar space (such as Artemis) to estimate their position, velocity and time as described in Giordano et al., (2023). Initial capabilities will focus on providing service to the lunar South pole region. The specification of AFS defines two orthogonal signal components on a single carrier, with the in-phase component (AFS-I) being a lower-chip-rate data channel tailored for applications where low SWaP is critical (e.g., IoT devices or search and rescue), and the quadrature component (AFS-Q) being a high-chip-rate data-less pilot signal for high-precision, robust lunar navigation and positioning applications. An initial description of AFS was provided in the LNIS, (2023), and initial analysis results were shown in Dafesh, et al., (2024). In this work, we provide rationale for updates to the LNIS that define key aspects of the signal including the primary spreading code designs for the data and pilot channels, and a three-tiered overlay code approach for the pilot channel that provides flexible signal acquisition alternatives, rapid time dissemination and robust frame Sync. The paper also describes a robust data sync word that is designed to enable frame Sync. for low-SWaP receivers that only use the I channel, as well as a low-density parity check code (LDPC) data message encoding design and interleaving definition. The work further describes the impact of the updated AFS design in terms of improved acquisition performance, interference resistance, navigation message capabilities and rapid absolute time dissemination for users able to access clock and ephemeris data over an external network. The cross-correlation and synchronization performance of the AFS design is also compared to potential alternatives, further providing rationale for the final signal design configuration.

LunaNet↗
NASA NTRS1994

Advanced technology for a satellite multichannel demultiplexer/demodulator

Satellite on-board processing is needed to efficiently service multiple users while at the same time minimizing earth station complexity. The processing satellite receives a wideband uplink at 30 GHz and down-converts it to a suitable intermediate frequency. A multichannel demultiplexer then separates the composite signal into discrete channels. Each channel is then demodulated by bulk demodulators, with the baseband signals routed to the downlink processor for retransmission to the receiving earth stations. This type of processing circumvents many of the difficulties associated with traditional bent-pipe repeater satellites. Uplink signal distortion and interference are not retransmitted on the downlink. Downlink power can be allocated in accordance with user needs, independent of uplink transmissions. This allows the uplink users to employ different data rates as well as different modulation and coding schemes. In addition, all downlink users have a common frequency standard and symbol clock on the satellite, which is useful for network synchronization in time division multiple access schemes. The purpose of this program is to demonstrate the concept of an optically implemented multichannel demultiplexer (MCD). A proof-of-concept (POC) model has been developed which has the ability to receive a 40 MHz wide composite signal consisting of up to 1000 40 kHz QPSK modulated channels and perform the demultiplexing process. In addition a set of special test equipment (STE) has been configured to evaluate the performance of the POC model. The optical MCD is realized as an acousto-optic spectrum analyzer utilizing the capability of Bragg cells to perform the required channelization. These Bragg cells receive an optical input from a laser source and an RF input (the signal). The Bragg interaction causes optical output diffractions at angles proportional to the RF input frequency. These discrete diffractions are optically detected and output to individual demodulators for baseband conversion. Optimization of the MCD design was conducted in order to achieve a compromise between two opposing sources of signal degradation: adjacent channel interference and intersymbol interference. The system was also optimized to allow simple, inexpensive ground stations communications with the MCD. These design goals led to the realization of a POC MCD which demonstrates the demultiplexing function with minimal signal degradation. Performance evaluation results using the STE equipment indicate that the dynamic range of the demultiplexer in the presence of adjacent and multiple channel loading is 40 - 50 dB. Measured bit error rate (BER) probabilities varied from the predicted theoretical results by one dB or less. The performance of the proof-of-concept model indicate that the development of a space qualified optically implemented MCD are feasible. The advantages to such an implementation include reduced size, weight and power and increased reliability when compared with electronic approaches. All of these factors are critical to on-board satellite processors. Further optimization can be conducted which trade ground station complexity and MCD performance to achieve desired system results.

Abramovitz, Irwin J.↗
NASA NTRS2009

Smart and Intelligent Sensors

John C. Stennis Space Center (SSC) provides rocket engine propulsion testing for NASA's space programs. Since the development of the Space Shuttle, every Space Shuttle Main Engine (SSME) has undergone acceptance testing at SSC before going to Kennedy Space Center (KSC) for integration into the Space Shuttle. The SSME is a large cryogenic rocket engine that uses Liquid Hydrogen (LH2) as the fuel. As NASA moves to the new ARES V launch system, the main engines on the new vehicle, as well as the upper stage engine, are currently base lined to be cryogenic rocket engines that will also use LH2. The main rocket engines for the ARES V will be larger than the SSME, while the upper stage engine will be approximately half that size. As a result, significant quantities of hydrogen will be required during the development, testing, and operation of these rocket engines.Better approaches are needed to simplify sensor integration and help reduce life-cycle costs. 1.Smarter sensors. Sensor integration should be a matter of "plug-and-play" making sensors easier to add to a system. Sensors that implement new standards can help address this problem; for example, IEEE STD 1451.4 defines transducer electronic data sheet (TEDS) templates for commonly used sensors such as bridge elements and thermocouples. When a 1451.4 compliant smart sensor is connected to a system that can read the TEDS memory, all information needed to configure the data acquisition system can be uploaded. This reduces the amount of labor required and helps minimize configuration errors. 2.Intelligent sensors. Data received from a sensor be scaled, linearized; and converted to engineering units. Methods to reduce sensor processing overhead at the application node are needed. Smart sensors using low-cost microprocessors with integral data acquisition and communication support offer the means to add these capabilities. Once a processor is embedded, other features can be added; for example, intelligent sensors can make a health assessment to inform the data acquisition client when sensor performance is suspect. 3.Distributed sample synchronization. Networks of sensors require new ways for synchronizing samples. Standards that address the distributed timing problem (for example, IEEE STD 1588) provide the means to aggregate samples from many distributed smart sensors with sub-microsecond accuracy. 4. Reduction in interconnect. Alternative means are needed to reduce the frequent problems associated with cabling and connectors. Wireless technologies offer the promise of reducing interconnects and simultaneously making it easy to quickly add a sensor to a system.

Lansaw, John↗
NASA NTRS2011

The Global Precipitation Measurement (GPM) Mission: Overview and U.S. Status

The Global Precipitation Measurement (GPM) Mission is an international satellite mission specifically designed to unify and advance precipitation measurements from a constellation of research and operational microwave sensors. The cornerstone of the GPM mission is the deployment of a Core Observatory in a 65 deg non-Sun-synchronous orbit to serve as a physics observatory and a transfer standard for inter-calibration of constellation radiometers. The GPM Core Observatory will carry a Ku/Ka-band Dual-frequency Precipitation Radar (DPR) and a conical-scanning multi-channel (10-183 GHz) GPM Microwave Radiometer (GMI). The first space-borne dual-frequency radar will provide not only measurements of 3-D precipitation structures but also quantitative information on microphysical properties of precipitating particles needed for improving precipitation retrievals from passive microwave sensors. The combined use of DPR and GMI measurements will place greater constraints on radiometer retrievals to improve the accuracy and consistency of precipitation estimates from all constellation radiometers. The GPM constellation is envisioned to comprise five or more conical-scanning microwave radiometers and four or more cross-track microwave sounders on operational satellites. NASA and the Japan Aerospace Exploration Agency (JAXA) plan to launch the GPM Core in July 2013. NASA will provide a second radiometer to be flown on a partner-provided GPM Low-Inclination Observatory (L10) to improve near real-time monitoring of hurricanes and mid-latitude storms. NASA and the Brazilian Space Program (AEB/IPNE) are currently engaged in a one-year study on potential L10 partnership. JAXA will contribute to GPM data from the Global Change Observation Mission-Water (GCOM-W) satellite. Additional partnerships are under development to include microwave radiometers on the French-Indian Megha-Tropiques satellite and U.S. Defense Meteorological Satellite Program (DMSP) satellites, as well as cross-track scanning humidity sounders on operational satellites such as the National Polar-orbiting Operational Environmental Satellite System (NPOESS) Preparatory Project (NPP), POES, the NASA/NOAA Joint Polar Satellite System (JPSS), and EUMETSAT MetOp satellites. Data from Chinese and Russian microwave radiometers may also become available through international collaboration under the auspices of the Committee on Earth Observation Satellites (CEOS) and Group on Earth Observations (GEO). The current generation of global rainfall products combines observations from a network of uncoordinated satellite missions using a variety of merging techniques. Relative to current data products, GPM's "nextgeneration" precipitation products will be characterized by: (1) more accurate instantaneous precipitation estimate (especially for light rain and cold-season solid precipitation), (2) more frequent sampling by an expanded constellation of microwave radiometers including operational humidity sounders over land, (3) intercalibrated microwave brightness temperatures from constellation radiometers within a unified framework, and (4) physical-based precipitation retrievals from constellation radiometers using a common a priori hydrometeor database constrained by combined radar/radiometer measurements provided by the GPM Core Observatory. An overview of the GPM mission concept, the U.S. GPM program status and updates on international science collaborations on GPM will be presented.

Hou, Arthur Y.↗
NASA NTRS2013

Wireless Integrated Microelectronic Vacuum Sensor System

NASA Stennis Space Center's (SSC's) large rocket engine test facility requires the use of liquid propellants, including the use of cryogenic fluids like liquid hydrogen as fuel, and liquid oxygen as an oxidizer (gases which have been liquefied at very low temperatures). These fluids require special handling, storage, and transfer technology. The biggest problem associated with transferring cryogenic liquids is product loss due to heat transfer. Vacuum jacketed piping is specifically designed to maintain high thermal efficiency so that cryogenic liquids can be transferred with minimal heat transfer. A vacuum jacketed pipe is essentially two pipes in one. There is an inner carrier pipe, in which the cryogenic liquid is actually transferred, and an outer jacket pipe that supports and seals the vacuum insulation, forming the "vacuum jacket." The integrity of the vacuum jacketed transmission lines that transfer the cryogenic fluid from delivery barges to the test stand must be maintained prior to and during engine testing. To monitor the vacuum in these vacuum jacketed transmission lines, vacuum gauge readings are used. At SSC, vacuum gauge measurements are done on a manual rotation basis with two technicians, each using a handheld instrument. Manual collection of vacuum data is labor intensive and uses valuable personnel time. Additionally, there are times when personnel cannot collect the data in a timely fashion (i.e., when a leak is detected, measurements must be taken more often). Additionally, distribution of this data to all interested parties can be cumbersome. To simplify the vacuum-gauge data collection process, automate the data collection, and decrease the labor costs associated with acquiring these measurements, an automated system that monitors the existing gauges was developed by Invocon, Inc. For this project, Invocon developed a Wireless Integrated Microelectronic Vacuum Sensor System (WIMVSS) that provides the ability to gather vacuum-gauge measurements automatically and wirelessly, in near-real time - using a low-maintenance, lowpower sensor mesh network. The WIMVSS operates by using a self-configuring mesh network of wireless sensor units. Mesh networking is a type of networking where each sensor or node can capture and disseminate its own data, but also serve as a relay to receive and transmit data from other sensors. Each sensor node can synchronize with adjacent sensors, and propagate data from one sensor to the next, until the destination is reached. In this case, the destination is a Network Interface Unit (NIU). The WIMVSS sensors are mounted on the existing vacuum gauges. Information gathered by the sensors is sent to the NIU. Because of the mesh networking, if a sensor cannot directly send the data to the NIU, it can be propagated through the network of sensors. The NIU requires antenna access to the sensor units, AC power, and an Ethernet connection. The NIU bridges the sensor network to a WIMVSS server via an Ethernet connection. The server is configured with a database, a Web server, and proprietary interface software that makes it possible for the vacuum measurements from vacuum jacketed fluid lines to be saved, retrieved, and then displayed from any Web-enabled PC that has access to the Internet. Authorized users can then simply access the data from any PC with Internet connection. Commands can also be sent directly from the Web interface for control and maintenance of the sensor network. The technology enabled by the WIMVSS decreases labor required for gathering vacuum measurements, increases access to vacuum data by making it available on any computer with access to the Internet, increases the frequency with which data points can be acquired for evaluating the system, and decreases the recurring cost of the sensors by using off-the-shelf components and integrating these with heritage vacuum gauges.

Krug, Eric↗
NASA NTRSDate not supplied

Flux Comparison of Master-8 and Ordem 3.1 Modelled Space Debris Population

With ESA’s Meteoroid And Space debris Terrestrial Environment Reference (MASTER-8) model and NASA’s Orbital Debris Engineering Model(ORDEM) 3.1, the two premier orbital debris engineering models have been officially released. The two models come with significant enhancements and now represent state-of-the-art orbital debris modelling for their respective agencies. Both models provide the community with estimates of the space debris environment from low Earth orbit (LEO) up to at least geostationary altitude. The MASTER population is an event-based simulation of all known events that generate debris and objects that are part of the U.S. Space Surveillance Network (SSN) catalog, which provides coverage of objects with diameters down to approximately 10cm in LEO and 1 m in geosynchronous Earth orbit (GEO). Different models are used to simulate the artificial objects and their orbit evolution over time. These models are called “sources” since they assign an origin to each individual object and consist of fragments, solid rocket motor (SRM) remainders, sodium-potassium(NaK) droplets, paintflakes, ejecta, and multi-layer insulation (MLI) fragments. The objects from each source are characterized by having individual release mechanisms, as well as orbital distributions, material composition, size, and mass distributions. Dedicated radar and telescope observation data is used to calibrate the model for objects larger than 1 cm in LEO and larger than 10 cm in GEO. For calibrating the small-sized objects, below 1 cm, impact data from returned surfaces are analyzed. Because the >1cm object population is dominated by fragments, the fragmentation event database was updated to include new events, as well as re-evaluate past events. Special attention was drawn to re-evaluating theFengyun-1C anti-satellite test from 2007 and Cosmos-Iridium collision event from 2009 since these events shape the fragment population because of their severity. After 2009, the two largest fragmentations in terms of number of tracked debris are the Briz-M explosion in 2012 and the NOAA-16explosion in 2015. In total, there are 261 confirmed fragmentations in the database up to November 2016.The baseline population for ORDEM 3.1 is based on the U.S. SSN catalog, and observational datasets from radar, in situ, and optical sources provide a foundation from which the model populations are statistically extrapolated to smaller size regions. These regions are not well-covered by the SSN catalog yet may pose the greatest threat to operational spacecraft. The NASA Standard Satellite Breakup Model is used to generate fragments greater than 1mm from collisions and explosions, and these fragment populations are scaled using ground-based radar data. Specific major debris-producing events, including the Fengyun-1C, Iridium 33, and Cosmos2251 debris clouds, and unique populations, such as NaK droplets, were re-examined, modelled, and added to the ORDEM environment separately. Optical measurement data is used to model the GEO population down to 10 cm. The debris environment is propagated using NASA’s LEO-to-GEO Environment Debris model, and future explosions of intact objects and collisions involving objects greater than 10 cm are assessed statistically. The environment from a few millimetres down to 10 𝜇m is modelled using a special degradation model where small particles are generated from intact spacecraft and rocket bodies, then the populations are scaled to fit in situ cratering data from Space Shuttle returned surfaces. Fragments smaller than 10 cm are differentiated based on material density categories, i.e., high-, medium-, and low-density, to better characterize the potential debris risk posed to upper stages and spacecraft. This paper will discuss the MASTER and ORDEM approaches for modelling populations and compare fluxes for specific orbits, including sun-synchronous, ISS-altitude, geosynchronous transfer, and GEO. In the end, a conclusion is drawn towards the importance of having multiple fundamentally different, yet validated, models to estimate the space debris population.

Andre Horstmann↗