Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Data Display”

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 1,549 records · Page 86
All sourcesNASA NTRSDOE OSTI
NASA NTRS1973

A Real-Time Phase Vector Display for EEG Monitoring

A real-time, computer-based, phase vector display system has been developed which will output a vector whose phase is equal to the delay between a trigger and the peak of a function which is quasi-coherent with respect to the trigger. The system also contains a sliding averager which enables the operator to average successive trials before calculating the phase vector. Data collection, averaging and display generation are performed on a LINC-8 computer. Output displays appear on several X-Y CRT display units and on a kymograph camera/oscilloscope unit which is used to generate photographs of time-varying phase vectors or contourograms of time-varying averages of input functions.

Finger, Herbert J.↗
NASA NTRS2012

Vandenberg Air Force Base Upper Level Wind Launch Weather Constraints

The 30th Operational Support Squadron Weather Flight (30 OSSWF) provides comprehensive weather services to the space program at Vandenberg Air Force Base (VAFB) in California. One of their responsibilities is to monitor upper-level winds to ensure safe launch operations of the Minuteman III ballistic missile. The 30 OSSWF tasked the Applied Meteorology Unit (AMU) to analyze VAFB sounding data with the goal of determining the probability of violating (PoV) their upper-level thresholds for wind speed and shear constraints specific to this launch vehicle, and to develop a tool that will calculate the PoV of each constraint on the day of launch. In order to calculate the probability of exceeding each constraint, the AMU collected and analyzed historical data from VAFB. The historical sounding data were retrieved from the National Oceanic and Atmospheric Administration Earth System Research Laboratory archive for the years 1994-2011 and then stratified into four sub-seasons: January-March, April-June, July-September, and October-December. The maximum wind speed and 1000-ft shear values for each sounding in each subseason were determined. To accurately calculate the PoV, the AMU determined the theoretical distributions that best fit the maximum wind speed and maximum shear datasets. Ultimately it was discovered that the maximum wind speeds follow a Gaussian distribution while the maximum shear values follow a lognormal distribution. These results were applied when calculating the averages and standard deviations needed for the historical and real-time PoV calculations. In addition to the requirements outlined in the original task plan, the AMU also included forecast sounding data from the Rapid Refresh model. This information provides further insight for the launch weather officers (LWOs) when determining if a wind constraint violation will occur over the next few hours on day of launch. The interactive graphical user interface (GUI) for this project was developed in Microsoft Excel using Visual Basic for Applications. The GUI displays the critical sounding data easily and quickly for the LWOs on day of launch. This tool will replace the existing one used by the 30 OSSWF, assist the LWOs in determining the probability of exceeding specific wind threshold values, and help to improve the overall upper winds forecast for the launch customer.

Shafer, Jaclyn A.↗
NASA NTRS1989

Data-Dictionary-Editing Program

Access to data-dictionary relations and attributes made more convenient. Data Dictionary Editor (DDE) application program provides more convenient read/write access to data-dictionary table ("descriptions table") via data screen using SMARTQUERY function keys. Provides three main advantages: (1) User works with table names and field names rather than with table numbers and field numbers, (2) Provides online access to definitions of data-dictionary keys, and (3) Provides displayed summary list that shows, for each datum, which data-dictionary entries currently exist for any specific relation or attribute. Computer program developed to give developers of data bases more convenient access to the OMNIBASE VAX/IDM data-dictionary relations and attributes.

Cumming, A. P.↗
NASA NTRS2003

Implementing an Automated Antenna Measurement System

We developed an automated measurement system using a PC running a LabView application, a Velmex BiSlide X-Y positioner, and a HP85l0C network analyzer. The system provides high positioning accuracy and requires no user supervision. After the user inputs the necessary parameters into the LabView application, LabView controls the motor positioning and performs the data acquisition. Current parameters and measured data are shown on the PC display in two 3-D graphs and updated after every data point is collected. The final output is a formatted data file for later processing.

Valerio, Matthew D.↗
NASA NTRS2006

Tool for Statistical Analysis and Display of Landing Sites

MarsLS is a software tool for analyzing statistical dispersion of spacecraft-landing sites and displaying the results of its analyses. Originally intended for the Mars Explorer Rover (MER) mission, MarsLS is also applicable to landing sites on Earth and non-MER sites on Mars. MarsLS is a collection of interdependent MATLAB scripts that utilize the MATLAB graphical-user-interface software environment to display landing-site data (see figure) on calibrated image-maps of the Martian or other terrain. The landing-site data comprise latitude/longitude pairs generated by Monte Carlo runs of other computer programs that simulate entry, descent, and landing. Using these data, MarsLS can compute a landing-site ellipse a standard means of depicting the area within which the spacecraft can be expected to land with a given probability. MarsLS incorporates several features for the user s convenience, including capabilities for drawing lines and ellipses, overlaying kilometer or latitude/longitude grids, drawing and/or specifying lines and/or points, entering notes, defining and/or displaying polygons to indicate hazards or areas of interest, and evaluating hazardous and/or scientifically interesting areas. As part of such an evaluation, MarsLS can compute the probability of landing in a specified polygonal area.

Wawrzyniak, Geoffrey↗
NASA NTRSDate not supplied

(ODIN): An Open Source, Low-Latency Data Integration & Visualization Framework for the NASA System Wide Safety Project's Disaster Response Safety Demonstration Series

The Open Data Integration Framework (ODIN) is an open source, low latency data integration and visualization framework (https://github.com/NASARace/race-odin) developed under NASA’s System WideSafety Program to demonstrate new safety capabilities designed to improve US airspace operations. Safety demonstrations are a set of increasingly complex (from public safety perspective) disaster response scenarios under which air systems must operate with increased capacity and include: 1) Wildland fire response, 2) Hurricane relief and recovery, 4) Emergency medical delivery via UAS and 4) Urban disaster relief. To accommodate disaster response, ODIN is field deployable and can scale on one or more multi-core, commodity laptops operating with full to limited or intermittent internet connectivity, conditions likely encountered during operations. ODIN runs as webserver with local, persistent data storage to serve either public or a secured, ad hoc network (e.g., an incident command post). The current released ODIN, ODIN-Fire is tailored for wildland fire management incorporating information on satellite overpasses with links to the near real-time data and imagery from the respective agencies. Included are winds data, an important variable for emergency responders and airspace operations, and high-resolution wind forecasts generated by super-computing resources and ingested into ODIN. As an open-source project, ODIN has attracted interest from multiple entities. We will show how 1) a commercial field instrument and data provider uses ODIN to help users visualize, publish and integrate their in-situ sensor network data and 2) ODIN’s capabilities to ingest, integrate and display near-real time satellite data with air traffic and a USFS winds forecast model used in fire response and post-fire assessment. Within NASA ODIN demonstrated novel, near terminal airspace safety capabilities for a project close-out event and previously it monitored the national airspace in real-time to meet an agency milestone. ODIN is presently under development for the anticipated hurricane relief and response demonstration notionally scheduled for the 2025-27 time frame and is available from NASA's github at the above link.

Aeronautics↗
NASA NTRS2006

Vehicle Transponder for Preemption of Traffic Lights

The purpose of this article is to describe, in more detail, the transponder installed in each vehicle that participates in the emergency traffic-light-preemption system described in the immediately preceding article. The transponder (see figure) is a fully autonomous data--collection, data-processing, information-display, and communication subsystem that performs robustly in preemption of traffic lights and monitoring of the statuses of street intersections. This transponder monitors the condition of the emergency vehicle in which it is installed and determines when the vehicle has been placed in an emergency-response condition with its siren and/or warning lights activated. Upon detection of such a condition, the transponder collects real-time velocity and acceleration data from the onboard diagnostic (OBD) computer of the vehicle. For this purpose, the transponder contains an OBD interface circuit, including a microprocessor that determines the manufacturer and model of the vehicle and then sends the appropriate commands to the OBD computer requesting the speed and acceleration data. At the same time, data from an onboard navigation system are collected to determine the location and the heading of the vehicle. Then acceleration, speed, position, and heading data are processed and combined with a vehicle-identification number and the resulting set of data is transmitted to monitoring and control units located at all intersections within communication range. When the unit at an intersection determines that this vehicle is approaching and has priority to preempt the intersection, it transmits a signal declaring the priority and the preemption to all participating vehicles (including this one) in the vicinity. If the unit at the intersection has determined that other participating vehicles are also approaching the intersection, then this unit also transmits, to the vehicle that has priority, a message that the other vehicles are approaching the same intersection. The texts of these messages, plus graphical symbols that show the directions and numbers of the approaching vehicles, are presented on the display panel of a computer that is part of the transponder.

Foster, Conrad↗
NASA NTRS2017

Mass and Reliability Source (MaRS) Database

The Mass and Reliability Source (MaRS) Database consolidates components mass and reliability data for all Oribital Replacement Units (ORU) on the International Space Station (ISS) into a single database. It was created to help engineers develop a parametric model that relates hardware mass and reliability. MaRS supplies relevant failure data at the lowest possible component level while providing support for risk, reliability, and logistics analysis. Random-failure data is usually linked to the ORU assembly. MaRS uses this data to identify and display the lowest possible component failure level. As seen in Figure 1, the failure point is identified to the lowest level: Component 2.1. This is useful for efficient planning of spare supplies, supporting long duration crewed missions, allowing quicker trade studies, and streamlining diagnostic processes. MaRS is composed of information from various databases: MADS (operating hours), VMDB (indentured part lists), and ISS PART (failure data). This information is organized in Microsoft Excel and accessed through a program made in Microsoft Access (Figure 2). The focus of the Fall 2017 internship tour was to identify the components that were the root cause of failure from the given random-failure data, develop a taxonomy for the database, and attach material headings to the component list. Secondary objectives included verifying the integrity of the data in MaRS, eliminating any part discrepancies, and generating documentation for future reference. Due to the nature of the random-failure data, data mining had to be done manually without the assistance of an automated program to ensure positive identification.

Valdenegro, Wladimir↗
DOE OSTI2018

AESD (Advanced Energy System Design) Records API [SWRs-17-50, 17-51, 17-52]

The Records API (application program interface) for Advanced Energy System Design (AESD) enables software that serves multidimensional record-oriented data to interoperate with software than uses such data. In the context of the Records API, multidimensional data records are simply tuples of real numbers, integers, and character strings, where each data value is tagged by a variable name, according to a pre-defined schema, and each record is assigned a unique integer identifier. Conceptually, these records are isomorphic to rows in a relational database, JSON objects, or key-value maps. Records servers might supply static datasets, sensor measurements that periodically update as new telemetry become available, or the results of simulations as the simulations generate new output. Records client software might display or analyze the data, but in the case of simulations the client request the creation of new ensembles for specified input parameters. It is also possible to chain records clients and servers together so that a client consuming data from a server might transform that data and serve it to additional clients. This minimalist API avoids imposing burdensome metadata, structural, or implementation requirements on developers by relying on open-source technologies that are readily available for common programming languages. In particular, the API has been designed to place the least possible burden on services that provide data. This document defines the message format for the Records API, a transport mechanism for communicating the data, and the semantics for interpreting it. The message format is specified as Google Protocol Buffers and the transport mechanism uses WebSockets. We discuss three major use cases for serving and consuming records data: (i) static data, (ii) dynamically augmented data, (iii) on-demand simulations, (iv) with filters, and (v) with bookmarks. Separate implementations of the API exist in C++, Haskell, JavaScript, Python, and R.

Bush, Brian↗
DOE OSTI2018

Advanced Energy System Design (AESD): Technical Manual for the Records API

The Records API (application program interface) for Advanced Energy System Design (AESD) enables software that serves multidimensional record-oriented data to interoperate with software than uses such data. In the context of the Records API, multidimensional data records are simply tuples of real numbers, integers, and character strings, where each data value is tagged by a variable name, according to a pre-defined schema, and each record is assigned a unique integer identifier. Conceptually, these records are isomorphic to rows in a relational database, JSON objects, or key-value maps. Records servers might supply static datasets, sensor measurements that periodically update as new telemetry become available, or the results of simulations as the simulations generate new output. Records client software might display or analyze the data, but in the case of simulations the client request the creation of new ensembles for specified input parameters. It is also possible to chain records clients and servers together so that a client consuming data from a server might transform that data and serve it to further clients. This minimalist API avoids imposing burdensome metadata, structural, or implementation requirements on developers by relying on open-source technologies that is readily available for common programming languages. In particular, the API has been designed to place the smallest possible burden on services that provide data. This document defines the message format for the Records API, a transport mechanism for communicating the data, and semantics for interpreting it. The message format is specified as Google Protocol Buffers and the transport mechanism uses WebSockets. We discuss three major use cases for serving and consuming records data: (i) static data, (ii) dynamically augmented data, (iii) on-demand simulations, (iv) with filters, and (v) with bookmarks. Separate implementations of the API exist in C++, Haskell, JavaScript, Python, and R.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1998

Real-Time Lunar Prospector Data Visualization Using Web-Based Java

The Lunar Prospector was co-developed by NASA Ames Research Center and Lockheed Martin, and was launched on January 6th, 1998. Its mission is to search for water ice and various elements in the Moon's surface, map its magnetic and gravity fields, and detect volcanic activity. For the first time, the World Wide Web is being used to graphically display near-real-time data from a planetary exploration mission to the global public. Science data from the craft's instruments, as well as engineering data for the spacecraft subsystems, are continuously displayed in time-varying XY plots. The craft's current location is displayed relative to the whole Moon, and as an off-craft observer would see in the reference frame of the craft, with the lunar terrain scrolling underneath. These features are implemented as Java applets. Analyzed data (element and mass distribution) is presented as 3D lunar maps using VRML and Javascript. During the development phase, implementations of the Java Virtual Machine were just beginning to mature enough to adequately accommodate our target featureset; incomplete and varying implementations were the biggest bottleneck to our ideal of ubiquitous browser access. Bottlenecks notwithstanding, the reaction from the Internet community was overwhelmingly enthusiastic.

Deardorff, D. Glenn↗
NASA NTRS1975

A study of payload specialist station monitor size constraints

Constraints on the CRT display size for the shuttle orbiter cabin are studied. The viewing requirements placed on these monitors were assumed to involve display of imaged scenes providing visual feedback during payload operations and display of alphanumeric characters. Data on target recognition/resolution, target recognition, and range rate detection by human observers were utilized to determine viewing requirements for imaged scenes. Field-of-view and acuity requirements for a variety of payload operations were obtained along with the necessary detection capability in terms of range-to-target size ratios. The monitor size necessary to meet the acuity requirements was established. An empirical test was conducted to determine required recognition sizes for displayed alphanumeric characters. The results of the test were used to determine the number of characters which could be simultaneously displayed based on the recognition size requirements using the proposed monitor size. A CRT display of 20 x 20 cm is recommended. A portion of the display area is used for displaying imaged scenes and the remaining display area is used for alphanumeric characters pertaining to the displayed scene. The entire display is used for the character alone mode.

Kirkpatrick, M., III↗
NASA NTRS1978

Cockpit displays and the growing role of the pilot in the ATC system

It is pointed out that advances in avionics and computer technology have reached the point where serious attention may be given to structuring a new controlled air traffic environment. The principal feature of such an environment is related to the capability of pilots to perform certain active ATC functions from the cockpit. The main function is concerned with the ability to maintain safe separation from other aircraft under all meteorological conditions. Technical features available to permit such a functional change include such concepts as the Discrete Address Beacon System, a full capability Beacon Collision Avoidance System, data links, computer generated displays, and flight management computers.

Lyman, E. G.↗
NASA NTRS1993

The early ultraviolet spectral evolution of Nova Cygni 1992

We report on the high resolution ultraviolet line profile evolution of Nova Cygni 1992 using the International Ultraviolet Explorer (IUE) satellite and the Goddard High Resolution Spectrograph (GHRS) on the Hubble Space Telescope (HST). Our observations cover the period from discovery in 1992 February through 1993 April. The initial expansion velocity, derived from P Cyg profiles on Mg II and other resonance lines, was about 4500 km/s. All resonance transitions displayed P Cyg profiles around the time of UV maximum. We first discuss the spectral development as the initially optically thick atomic absorption curtain became optically thin. We then present the interpretation of the nebular spectral stage. The high resolution line profiles show that the shell rapidly developed nearly symmetric knots, or filaments, of emission. The optically thin transitions show an emission weighted expansion velocity of about 1800 km/s, consistent with the velocity inferred from the radio and infrared data. The emission lines display a symmetric set of filaments that appeared as soon as the line profiles became optically thin. The GHRS observations demonstrate that the filaments were located in the inner, slower moving parts of the ejecta. These probably record an initial low wave number instability imposed on the ejecta at the time of outburst. We suggest that the likely cause is a Rayleigh-Taylor instability. The emission at later stages is dominated by the filaments and, since this phenomenon is seen in virtually all novae, nebular line formation codes will have to account for the density inhomgeneities in order to adequately determine abundances for nove ejecta.

Shore, Steven N.↗
NASA NTRS2013

Orion Scripted Interface Generator (OrionSIG)

The Orion spacecraft undergoing development at NASA and Lockheed Martin aims to launch the first humans to set foot on asteroids and Mars.' Sensors onboard Orion must transmit back to Earth astronomical amounts of data recording almost everything in 50,231 lb. (22,784 kg)2 of spacecraft, down to the temperatures, voltages, or torsions of even the most minor components. This report introduces the new Orion Scripted Interface Generator (OrionSIG) software created by summer 2013 NASA interns Robert Dooling and Samuel Harris. OrionSIG receives a list of Orion variables and produces a script to graph these measurements regardless of their size or type. The program also accepts many other input options to manipulate displays, such as limits on the graph's range or commands to graph different values in a reverse sawtooth wave. OrionSIG paves the way for monitoring stations on Earth to process, display, and test Orion data much more efficiently, a helpful asset in preparation for Orion's first test mission in 2014. Figure I.

Dooling, Robert J.↗
NASA NTRS2015

Java Architecture for Detect and Avoid Extensibility and Modeling

Unmanned aircraft will equip with a detect-and-avoid (DAA) system that enables them to comply with the requirement to "see and avoid" other aircraft, an important layer in the overall set of procedural, strategic and tactical separation methods designed to prevent mid-air collisions. This paper describes a capability called Java Architecture for Detect and Avoid Extensibility and Modeling (JADEM), developed to prototype and help evaluate various DAA technological requirements by providing a flexible and extensible software platform that models all major detect-and-avoid functions. Figure 1 illustrates JADEM's architecture. The surveillance module can be actual equipment on the unmanned aircraft or simulators that model the process by which sensors on-board detect other aircraft and provide track data to the traffic display. The track evaluation function evaluates each detected aircraft and decides whether to provide an alert to the pilot and its severity. Guidance is a combination of intruder track information, alerting, and avoidance/advisory algorithms behind the tools shown on the traffic display to aid the pilot in determining a maneuver to avoid a loss of well clear. All these functions are designed with a common interface and configurable implementation, which is critical in exploring DAA requirements. To date, JADEM has been utilized in three computer simulations of the National Airspace System, three pilot-in-the-loop experiments using a total of 37 professional UAS pilots, and two flight tests using NASA's Predator-B unmanned aircraft, named Ikhana. The data collected has directly informed the quantitative separation standard for "well clear", safety case, requirements development, and the operational environment for the DAA minimum operational performance standards. This work was performed by the Separation Assurance/Sense and Avoid Interoperability team under NASA's UAS Integration in the NAS project.

unmanned aircraft systems↗
NASA NTRS1984

Studies of lightning data in conjunction with geostationary satellite data

The archiving of a more complete data base to perform lightning studies is outlined. This effort includes: (1) continued archiving of bureau of land management LLP, geostationary satellite, and NWS radar data; (2) expansion of the McIDAS real-time LLP access to other networks. Additional processing tools for display and analysis of lightning location data in conjunction with geostationary satellite data are developed which entails adapting existing McIDAS software to allow the production of statistical summaries and contouring of lightning characteristics over user defined areas or storms. The plotting of three dimensional displays of lightning statistics versus satellite and radar data, and the performance of an error analysis of lightning location data using overlapping regions of the BLM network are discussed.

Suchman, D.↗
NASA NTRS1985

Studies of lightning data in conjunction with geostationary satellite data

Since January, work has been proceeding on the first phase of this project: the creation of an extensive real-time lightning data base accessible via the Space Science and Engineering Center McIdas system. The purpose of this endeavor is two-fold: to enhance the availability and ease of access to lightning data among the various networks, governmental and research agencies; and to test the feasiblity and desirability of such efforts in succeeding years. The final steps in the creation of the necessary communications links, hardware, and software are in the process of being completed. Operations ground rules for access among the various users have been discussed and are being refined. While the research planned for the last year of the project will rely for the most part on archived, quality-controlled data from the various networks, the real-time data will provide a valuable first-look at potentially interesting case studies. For this purpose, tools are being developed on McIdas for display and analysis of the data as they become available. In conjunction with concurrent GOES real-time imagery, strike locations can be plotted, gridded and contoured, or displayed in various statistical formats including frequency distributions, histograms, and scatter plots. The user may also perform these functions in relation to arbitrarily defined areas on the satellite image. By mid-May these preparations for the access and analysis of real-time lightning data are expected to be complete.

Auvine, B.↗