Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “CuI”

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 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2018

CAIDA CUI Confirmation for OMRS & LCC SOCRRATES Emulator and iSEE Upgrade, Operations, & Analysis

This internship has focused on providing solutions for the Customer Avionics Interface Development and Analysis (CAIDA) subsystem. The main emulator that has been used during this internship is the Software-Only CEV (Crew Exploration Vehicle) Risk Reduction Analysis and Test Engineering Simulator (SOCRRATES). This emulator uses advanced math and physics methods to simulate specific points in a mission, such as ascent, entry, and orbit. Exploration Ground Systems (EGS) must ensure that all KSC based ground systems can be properly integrated with the flight vehicle software, therefore, the Modeling and Simulation Branch (NE-XM) of the KSC (Kennedy Space Center) Engineering Directorate supports a virtual environment that simulates the interface between ground systems and the flight vehicle. A primary component in assuring that is knowing whether the emulators have incorporated the correct CUIs (Compact Unique Identifiers) into their system, as well as understanding both the static and dynamic responses of the individual CUIs. Also, an effort for verification of Operational Maintenance Requirements Specifications (OMRS) and Launch Commit Criteria (LCC) that are supported by SOCRRATES for the Orion Crew Module were part of the project tasks this semester. This internship also focused on comparing two different simulation Commercial-off-the-shelf (COTS) products and to determine whether or not a COTS package was a viable replacement for the current software that the iSEE (Immersive Simulations and Engineering Environment) lab uses. Upon research and testing, I found that this software was not feasible for the lab. It could not easily load CAD (Computer-Aided Design) or CREO models, give live feedback while the user is in the environment, and was not compatible with a virtual reality headset, all of which are necessary for the lab.

Bundy, Caleb↗
NASA NTRS1994

CuI by XPS

X-ray photoemission measurements of high purity CuI are presented.

X-ray photoemission XPS CuI Cu compounds supercond↗
NASA NTRS2012

Orion Script Generator

NASA Engineering's Orion Script Generator (OSG) is a program designed to run on Exploration Flight Test One Software. The script generator creates a SuperScript file that, when run, accepts the filename for a listing of Compact Unique Identifiers (CUIs). These CUIs will correspond to different variables on the Orion spacecraft, such as the temperature of a component X, the active or inactive status of another component Y, and so on. OSG will use a linked database to retrieve the value for each CUI, such as "100 05," "True," and so on. Finally, OSG writes SuperScript code to display each of these variables before outputting the ssi file that allows recipients to view a graphical representation of Orion Flight Test One's status through these variables. This project's main challenge was creating flexible software that accepts and transfers many types of data, from Boolean (true or false) values to "Unsigned Long Long'' values (any number from 0 to 18,446,744,073,709,551,615). We also needed to allow bit manipulation for each variable, requiring us to program functions that could convert any of the multiple types of data into binary code. Throughout the project, we explored different methods to optimize the speed of working with the CUI database and long binary numbers. For example, the program handled extended binary numbers much more efficiently when we stored them as collections of Boolean values (true or false representing 1 or 0) instead of as collections of character strings or numbers. We also strove to make OSG as user-friendly and accommodating of different needs as possible its default behavior is to display a current CUI's maximum value and minimum value with three to five intermediate values in between, all in descending order. Fortunately, users can also add other input on the same lines as each CUI name to request different high values, low values, display options (ascending, sine, and so on), and interval sizes for generating intermediate values. Developing input validation took up quite a bit of time, but OSG's flexibility in the end was worth it.

Dooling, Robert J.↗
NASA NTRS2014

SSL Freeform Generator v1.00

The Orion spacecraft utilizes a system of Compact Unique Identifiers (CUIs) to identify telemetry measurements in the process of communicating with the ground. While avionic systems are still in development, simulation of telemetric data must be used for the development of dependent systems. The SuperScript Language (SSL) developed by Honeywell Aerospace provides users a programming language for simulation of this data. The use of tools that provide SSL generation capabilities at a higher level allows for faster and more efficient generation of simulation waveforms. Previous SSL Generator implementations such as Orion Scripted Interface Generator (OrionSIG) relied on software supported routines to generate simulation points for the SSL scripts. This provided relevant simulation capabilities, but was reduced in flexibility by the available software routines available. For this approach, software supported routines have been entirely dropped. Rather, the user is required to enter their own simulation waveform input. This allows arbitrarily complex functions to be utilized simulated with maximum degree of freedom for the user.: The idea for this version of the SSL Generator was a mapping of arbitrary waveforms to Orion CUI telemetry data. The SSL Generator implemented offers a higher degree of freedom to the user than previous versions while attempting to maintain abstraction from the underlying SSL script and the Orion CUI data types. As such, many mappings of waveforms to CUIs will simply not work. Certain implementation decisions were made to minimize the damage caused by these unintended side-effects, such as saturation of values exceeding the maximum or minimum bounds of the data type. Other details, such as signed values being represented in unsigned data types, present problems which cant be fixed to an acceptable degree of intended behavior without user input. Awareness of the limitations of all layers of the software stack will increase the productivity of the end-user.

telemetry↗
NASA NTRS1989

Wet chemical techniques for passivation of YBa2Cu3O7(7-x)

Wet chemical techniques are described for treatment of YBa2Cu3O(7-x) surfaces, resulting in the formation of native compounds with little or no reactivity to water. Promising native compounds include CuI, BaSO4, CuS, Cu2S, and the oxalates, all of which are either insoluble or have very low solubility in water. Treatment with dilute HI results in the formation of a native iodide film which is 80-90 percent CuI with small amounts of YI3 and BaI2. Treatment with dilute H2SO4 results in the formation of a film which is 95 percent BaSO4 and 5 percent Y2(SO4)3. Cu2S is formed on the surface with a dilute Na2S solution. An oxalate film with equal amounts of Y2(C2O4)3 and BaC2O4 results from treatment with dilute oxalic acid. X-ray photoelectron spectra show no significant changes when the sulfide, sulfate, or oxalate films are dipped in water, while the iodide film shows evidence of Cu(OH)2 formation.

Vasquez, R. P.↗
NASA NTRS1991

Cooperative processing user interfaces for AdaNET

A cooperative processing user interface (CUI) system shares the task of graphical display generation and presentation between the user's computer and a remote host. The communications link between the two computers is typically a modem or Ethernet. The two main purposes of a CUI are reduction of the amount of data transmitted between user and host machines, and provision of a graphical user interface system to make the system easier to use.

Gutzmann, Kurt M.↗
NASA NTRS1992

ASV3 dial-in interface recommendation for the Repository Based Software Engineering (RBSE) program

The purpose of this report is to provide insight into the approach and design of the Cooperative User Interface (CUI). The CUI is being developed based on Hypercard technology and will provide the same look and feel as is provided by the NASA Electronic Library System (NELS) X-Window interface. The interaction between the user and ASCII-LIB is presented as well as the set of Hypercard Cards with which the user will work.

Source record↗
NASA NTRS2008

Use of Spacecraft Command Language for Advanced Command and Control Applications

The purpose of this work is to evaluate the use of SCL in building and monitoring command and control applications in order to determine its fitness for space operations. Approximately 24,325 lines of PCG2 code was converted to SCL yielding a 90% reduction in the number of lines of code as many of the functions and scripts utilized in SCL could be ported and reused. Automated standalone testing, simulating the actual production environment, was performed in order to generalize and gauge the relative time it takes for SCL to update and write a given display. The use of SCL rules, functions, and scripts allowed the creation of several test cases permitting the detection of the amount of time it takes update a given set of measurements given the change in a globally existing CUI or CUI. It took the SCL system an average 926.09 ticks to update the entire display of 323 measurements.

Mims, Tikiela L.↗
NASA NTRS2014

Design and Development of Functionally Operative and Visually Appealing Remote Firing Room Displays

This internship provided an opportunity for an intern to work with NASA's Ground Support Equipment (GSE) for the Spaceport Command and Control System (SCCS) at Kennedy Space Center as a remote display developer, under NASA mentor Kurt Leucht. The main focus was on creating remote displays for the hypergolic and high pressure helium subsystem team to help control the filling of the respective tanks. As a remote display developer for the GSE hypergolic and high pressure helium subsystem team the intern was responsible for creating and testing graphical remote displays to be used in the Launch Control Center (LCC) on the Firing Room's computer monitors. To become more familiar with the subsystem, the individual attended multiple project meetings and acquired their specific requirements regarding what needed to be included in the remote displays. After receiving the requirements, the next step was to create a display that had both visual appeal and logical order using the Display Editor, on the Virtual Machine (VM). In doing so, all Compact Unique Identifiers (CUI), which are associated with specific components within the subsystem, will need to be included in each respective display for the system to run properly. Then, once the display was created it needed to be tested to ensure that the display runs as intended by using the Test Driver, also found on the VM. This Test Driver is a specific application that checks to make sure all the CUIs in the display are running properly and returning the correct form of information. After creating and locally testing the display it will need to go through further testing and evaluation before deemed suitable for actual use. By the end of the semester long experience at NASA's Kennedy Space Center, the individual should have gained great knowledge and experience in various areas of display development and testing. They were able to demonstrate this new knowledge obtained by creating multiple successful remote displays that will one day be used by the hypergolic and high pressure helium subsystem team in one of the LCC's firing rooms to fill the new Orion spacecraft.

Ground Support Systems↗
NASA NTRS2014

Development and Testing of Functionally Operative and Visually Appealing Remote Firing Room Displays and Applications

This internship provided an opportunity for an intern to work with NASA's Ground Support Equipment (GSE) for the Spaceport Command and Control System (SCCS) at Kennedy Space Center as a remote display developer, under NASA technical mentor Kurt Leucht. The main focus was on creating remote displays and applications for the hypergolic and high pressure helium subsystem team to help control the filling of the respective tanks. As a remote display and application developer for the GSE hypergolic and high pressure helium subsystem team the intern was responsible for creating and testing graphical remote displays and applications to be used in the Launch Control Center (LCC) on the Firing Room's computers. To become more familiar with the subsystem, the individual attended multiple project meetings and acquired their specific requirements regarding what needed to be included in the software. After receiving the requirements for the displays, the next step was to create displays that had both visual appeal and logical order using the Display Editor, on the Virtual Machine (VM). In doing so, all Compact Unique Identifiers (CUI), which are associated with specific components within the subsystem, were need to be included in each respective display for the system to run properly. Then, once the display was created it was to be tested to ensure that the display runs as intended by using the Test Driver, also found on the VM. This Test Driver is a specific application that checks to make sure all the CUIs in the display are running properly and returning the correct form of information. After creating and locally testing the display it needed to go through further testing and evaluation before deemed suitable for actual use. For the remote applications the intern was responsible for creating a project that focused on channelizing each component included in each display. The core of the application code was created by setting up spreadsheets and having an auto test generator, generate the complete code structure. This application code was then loaded and ran on a testing environment set to ensure the code runs as anticipated. By the end of the semester-long experience at NASA's Kennedy Space Center, the individual should have gained great knowledge and experience in various areas of both display and application development and testing. They were able to demonstrate this new knowledge obtained by creating multiple successful remote displays that will one day be used by the hypergolic and high pressure helium subsystem team in the LCC's firing rooms to service the new Orion spacecraft. The completed display channelization application will be used to receive verification from NASA quality engineers.

Display Devices↗
NASA NTRS2017

Environmental Control System Software & Hardware Development

ECS hardware: (1) Provides controlled purge to SLS Rocket and Orion spacecraft. (2) Provide mission-focused engineering products and services. ECS software: (1) NASA requires Compact Unique Identifiers (CUIs); fixed-length identifier used to identify information items. (2) CUI structure; composed of nine semantic fields that aid the user in recognizing its purpose.

student↗
NASA NTRS1986

Carrier surface generation and recombination effects in photoconduction of HgI2 single crystals

Dc photoconductivity characteristics of HgI2 single crystals have been measured in the range of 1.75-2.75 eV, using CuI as a transparent electrical contact. Hole and electron photocurrents could be separately measured by applying different voltage polarities to the illuminated electrode. It is shown that charge carrier generation near the surface is highly extrinsic, as displayed by differences in the hole and electron photogeneration spectra. Analysis of the photoconductivity versus voltage characteristics indicates that the hole and electron bulk trapping times satisfy greater than 70 and 3 microsec, respectively. The hole and electron surface recombination velocities were 1.0 x 10 to the 4th cm/s and 8 x 10 to the 5th cm/s, respectively.

Burshtein, Z.↗
NASA NTRS1990

Wet chemical passivation of YBa2Cu3O(7-x)

Wet chemical techniques are described for treatment of YBa2Cu3O(7-x) surfaces, which result in the formation of native compounds known to have little or no reactivity to water. Suitable native compounds include CuI, BaSO4, CuS, Cu2S, YF3, and the oxalates. Formation of surface layers in which these nonreactive native compounds are major constituents is verified with X-ray photoelectron spectroscopy (XPS) measurements on YBa2Cu3O(7-x) films treated with dilute solutions of HI, H2SO4, Na2S, HF, or H2C2O4. No significant changes are observed in the XPS spectra when the sulfide, sulfate, or oxalate films are dipped in water, while the iodide and fluoride films show evidence of reaction with water. X-ray diffraction measurements show that the superconducting phase is absent in the sulfide film, but is unaffected by the oxalate and sulfate treatments.

Vasquez, R. P.↗
NASA NTRS1999

RXTE Observation of 4U 1630-47 During its 1998 Outburst

During the 1998 outburst of 4U 1630-47 it was extensively observed with the Rossi X-ray Timing Explorer (RXTE). In order to cover the outburst more thoroughly our data (Obs. ID: 30178-0[1-2]- ) were combined with those of Cui et al. (Obs. ID: 30188-02-). These observations were later compared with the complementary observations. Power density and energy spectra have been made for each observation. The data was used to place radio and hard X-ray observations within context. Analysis of SAX (Satellite per Astronomia a raggi X) and BATSE (Burst and Transient Source Experiment) data was also included within the study. The count rate and position in hardness-intensity, color-color diagrams and simple spectral fits are used to track the concurrent spectral changes. The source showed seven distinct types of timing behavior, most of which show differences with the canonical black hole spectral/timing states. In marked contrast to previous outbursts, we find quasi-periodic oscillation (QPO) signals during nearly all stages of the outburst with frequencies between 0.06 Hz and 14 Hz and a remarkable variety of other characteristics. In particular we find large (up to 23% rms) amplitude QPO on the early rise. Later, slow 0.1 Hz semi- regular short (- 5 sec), 9 to 16% deep dips dominate the light curve. At this time there are two QPOS, one stable near 13.5 Hz and the other whose frequency drops from 6-8 Hz to - 4.5 Hz during the dips. BeppoSAX observations during the very late declining phase show 4U 1630-47 in a low state. These results will shortly be published. We are completing a detailed analysis of the energy spectra (in preparation). The QPO/noise properties are being correlated with the concurrent spectral changes. Detailed studies of the QPO are being undertaken using sophisticated timing analysis methods. Finally a comparison with the other outbursts of 1630-47 is being made.

Dieters, Stefan W.↗
NASA NTRS2000

Successful Hybrid Approach to Visual and Video Observations of the 1999 Leonid Storm

A new hybrid technique of visual and video meteor observations is described. The method proved particularly effective for airborne observations of meteor shower activity. Results from the 1999 Leonid Multi-Instrument Aircraft Campaign are presented, and the profile shape of the 1999 Leonid storm is discussed in relation to meteor shower models. We find that the storm is best described with a Lorentz profile. Application to past meteor outbursts shows that the cui,rent multi-trailet model of a dust trail is slightly shifted and we crossed deeper into the 1899 epoch trallet than expected.

Jenniskens, Peter↗
NASA NTRS2011

MODIS Radiometric Calibration and Uncertainty Assessment

Since launch, Terra and Aqua MODIS have collected more than II and 9 years of datasets for comprehensive studies of the Earth's land, ocean, and atmospheric properties. MODIS observations are made in 36 spectral bands: 20 reflective solar bands (RSB) and 16 thermal emissive bands (TEB). Compared to its heritage sensors, MODIS was developed with very stringent calibration and uncertainty requirements. As a result, MODIS was designed and built with a set of state of the art on-board calibrators (OBC), which allow key sensor performance parameters and on-orbit calibration coefficients to be monitored and updated if necessary. In terms of its calibration traceability, MODIS RSB calibration is reflectance based using an on-board solar diffuser (SD) and the TEB calibration is radiance based using an on-board blackbody (BB). In addition to on-orbit calibration coefficients derived from its OBC, calibration parameters determined from sensor pre-launch calibration and characterization are used in both the RSB and TEB calibration and retrieval algorithms. This paper provides a brief description of MODIS calibration methodologies and discusses details of its on-orbit calibration uncertainties. It assesses uncertainty contributions from individual components and differences between Terra and Aqua MODIS due to their design characteristics and on-orbit periormance. Also discussed in this paper is the use of MODIS LIB uncertainty index CUI) product.

Xiong, Xiaoxiong↗
NASA NTRS2013

Master Console, SMC

The Master Console oversees the function of Computer Systems in Firing room 1 (FR1). Master Console Operators, MCOs' for short, are our customer. I was integrated into the System Monitoring and Control (SMC) software team that is under the guidance of David Slaiman, who is the product group lead. I have been brought up to speed with System Monitoring and Control. The initial time spent reading SMC software design description and understanding how it works. The current Firing Room 1 Console Display is a floor layout giving the MCO two essential pieces of information which are Health and Status. When an issue arises, the MCO has to look on the display to find which console is affected and then the MCO must use the Reference designator from the display to manually search for the Portal Workstation (PWS) installed in the console using the hardware map; which is a long process to lookup a PWS if an issue is present. My project is to make the FR1 Console Display easier for the MCO's to pinpoint PWS's without having to lookup additional resources in the process. My project also includes updating Firing Room 1 Console Display to include the F1R Non-Redundant Set. The display does not have good use of space and functionality. PWS numbers were not present in the previous design and are the critical component in efficient understanding and administration of the consoles. Part of the process includes getting feedback from the customer, instead of just emailing them with a question, we made a proposal with changes so they could respond and give us their input; which proved to be an effective method for engaging them. In order to do this I had to use the Display Editor (DE) tool developed by NASA, Paint.Net and Visio. The process I have been using has been Visio to alter the floor layout of Firing Room and take advantage of the white areas, and then I take the altered floor plan into Paint.Net. Once in Paint.Net I put the new floor plan as a background to the standard console display. Paint.Net also serves as a tool to create the new service state bars for the new background; finally I used the DE to assemble everything and setup the right CUI's for each PWS.

MCO↗
NASA NTRS2013

Display Developer for Firing Room Applications

The firing room at Kennedy Space Center (KSC) is responsible for all NASA human spaceflight launch operations, therefore it is vital that all displays within the firing room be properly tested, up-to-date, and user-friendly during a launch. The Ground Main Propulsion System (GMPS) requires a number of remote displays for Vehicle Integration and Launch (VIL) Operations at KSC. My project is to develop remote displays for the GMPS using the Display Services and Framework (DSF) editor. These remote displays will be based on model images provided by GMPS through PowerPoint. Using the DSF editor, the PowerPoint images can be recreated with active buttons associated with the correct Compact Unique Identifiers (CUIs). These displays will be documented in the Software Requirements and Design Specifications (SRDS) at the 90% GMPS Design Review. In the future, these remote displays will be available for other developers to improve, edit, or add on to so that the display may be incorporated into the firing room to be used for launches.

Firing Room Application↗