Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “data formats”

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,099 records · Page 61
All sourcesNASA NTRSDOE OSTI
NASA NTRS1994

Stand-alone digital data storage control system including user control interface

A storage control system includes an apparatus and method for user control of a storage interface to operate a storage medium to store data obtained by a real-time data acquisition system. Digital data received in serial format from the data acquisition system is first converted to a parallel format and then provided to the storage interface. The operation of the storage interface is controlled in accordance with instructions based on user control input from a user. Also, a user status output is displayed in accordance with storage data obtained from the storage interface. By allowing the user to control and monitor the operation of the storage interface, a stand-alone, user-controllable data storage system is provided for storing the digital data obtained by a real-time data acquisition system.

Wright, Kenneth D.↗
NASA NTRS2017

Engine Icing Data - An Analytics Approach

Engine icing researchers at the NASA Glenn Research Center use the Escort data acquisition system in the Propulsion Systems Laboratory (PSL) to generate and collect a tremendous amount of data every day. Currently these researchers spend countless hours processing and formatting their data, selecting important variables, and plotting relationships between variables, all by hand, generally analyzing data in a spreadsheet-style program (such as Microsoft Excel). Though spreadsheet-style analysis is familiar and intuitive to many, processing data in spreadsheets is often unreproducible and small mistakes are easily overlooked. Spreadsheet-style analysis is also time inefficient. The same formatting, processing, and plotting procedure has to be repeated for every dataset, which leads to researchers performing the same tedious data munging process over and over instead of making discoveries within their data. This paper documents a data analysis tool written in Python hosted in a Jupyter notebook that vastly simplifies the analysis process. From the file path of any folder containing time series datasets, this tool batch loads every dataset in the folder, processes the datasets in parallel, and ingests them into a widget where users can search for and interactively plot subsets of columns in a number of ways with a click of a button, easily and intuitively comparing their data and discovering interesting dynamics. Furthermore, comparing variables across data sets and integrating video data (while extremely difficult with spreadsheet-style programs) is quite simplified in this tool. This tool has also gathered interest outside the engine icing branch, and will be used by researchers across NASA Glenn Research Center. This project exemplifies the enormous benefit of automating data processing, analysis, and visualization, and will help researchers move from raw data to insight in a much smaller time frame.

Engine Icing↗
NASA NTRS2019

The Seismic Experiment for Interior Structure (SEIS): Experiment Data Distribution

The six sensors of SEIS (The Seismic Experiment for Interior Structure) [- one of three primary instruments on NASA's Mars Lander Insight] cover a broad range of the seismic bandwidth, from 0.01 hertz to 50 hertz, with possible extension to longer periods. Data are transmitted in the form of three continuous VBB (Very Broad-Band) components at 2 samples per second (sps), an estimation of the short period (SP) energy content from the SP at 1 sps, and a continuous compound VBB/SP vertical axis at 10 sps. The continuous streams are augmented by requested event data with sample rates from 20 to 100 sps. SEIS data products are downlinked from the spacecraft in raw CCSDS (Consultative Committee for Space Data Systems) packets and converted to both the Standard for the Exchange of Earthquake Data (SEED) format files and ASCII tables (GeoCSV) for analysis and archiving. Metadata are available in dataless SEED and StionXML. Time series data (waveforms) are available in miniseed and GeoCSV. Data are distributed according to FDSN (Federation of Digital Seismograph Networks - http://www.fdsn.org) formats and interfaces. Wind, pressure and temperature data from the Auxiliary Payload Sensor Suite (APSS) will also be available in SEED format, and can be used for decorrelation and diagnostic purposes on SEIS.

Pardo, Constanza↗
NASA NTRS1987

Manual for Getdata Version 3.1: a FORTRAN Utility Program for Time History Data

This report documents version 3.1 of the GetData computer program. GetData is a utility program for manipulating files of time history data, i.e., data giving the values of parameters as functions of time. The most fundamental capability of GetData is extracting selected signals and time segments from an input file and writing the selected data to an output file. Other capabilities include converting file formats, merging data from several input files, time skewing, interpolating to common output times, and generating calculated output signals as functions of the input signals. This report also documents the interface standards for the subroutines used by GetData to read and write the time history files. All interface to the data files is through these subroutines, keeping the main body of GetData independent of the precise details of the file formats. Different file formats can be supported by changes restricted to these subroutines. Other computer programs conforming to the interface standards can call the same subroutines to read and write files in compatible formats.

Maine, Richard E.↗
DOE OSTI2020

Air temperature and relative humidity raw data from June 2017-Oct 2018 at the B34 tower in Manaus, Brazil

This data package contains raw data from stomatal conductance and leaf temperature measurements from the B34 tower at the NGEE Tropics site in Manaus, Brazil. Related data packages, including additional metadata such as site information and equipment manuals, are included in the data package listed under Dataset Reference(s). Air temperature and relative humidity data were obtained using a thermohygrometer (HC2S3, Campbell Scientific®) installed in tower K34 making a profile of (HR_: 7m, HR_2: 14m, HR_3: 21m). Data files are included in CSV and Excel file formats. No data processing or QA/QC was done on the raw datasets. Processed datasets will be uploaded separately. Contact israelmdt@gmail.com if you need to use this dataset for additional information.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS2011

IONAC-Lite

The Interplanetary Overlay Net - working Protocol Accelerator (IONAC) described previously in The Inter - planetary Overlay Networking Protocol Accelerator (NPO-45584), NASA Tech Briefs, Vol. 32, No. 10, (October 2008) p. 106 (http://www.techbriefs.com/component/ content/article/3317) provides functions that implement the Delay Tolerant Networking (DTN) bundle protocol. New missions that require high-speed downlink-only use of DTN can now be accommodated by the unidirectional IONAC-Lite to support high data rate downlink mission applications. Due to constrained energy resources, a conventional software implementation of the DTN protocol can provide only limited throughput for any given reasonable energy consumption rate. The IONAC-Lite DTN Protocol Accelerator is able to reduce this energy consumption by an order of magnitude and increase the throughput capability by two orders of magnitude. In addition, a conventional DTN implementation requires a bundle database with a considerable storage requirement. In very high downlink datarate missions such as near-Earth radar science missions, the storage space utilization needs to be maximized for science data and minimized for communications protocol-related storage needs. The IONAC-Lite DTN Protocol Accelerator is implemented in a reconfigurable hardware device to accomplish exactly what s needed for high-throughput DTN downlink-only scenarios. The following are salient features of the IONAC-Lite implementation: An implementation of the Bundle Protocol for an environment that requires a very high rate bundle egress data rate. The C&DH (command and data handling) subsystem is also expected to be very constrained so the interaction with the C&DH processor and the temporary storage are minimized. Fully pipelined design so that bundle processing database is not required. Implements a lookup table-based approach to eliminate multi-pass processing requirement imposed by the Bundle Protocol header s length field structure and the SDNV (self-delimiting numeric value) data field formatting. 8-bit parallel datapath to support high data-rate missions. Reduced resource utilization implementation for missions that do not require custody transfer features. There was no known implementation of the DTN protocol in a field programmable gate array (FPGA) device prior to the current implementation. The combination of energy and performance optimization that embodies this design makes the work novel.

Torgerson, Jordan L.↗
NASA NTRS2018

A Concept for Civil Space Traffic Management

As technology has improved, operators have sought to use cubesats, as well as smallsats more generally, to perform increasingly more ambitious and sophisticated functions. Despite this, practical concerns associated with cubesat infant mortality, conjunctions, limited maneuverability, and debris generation have been relatively muted because most cubesats have been launched to lower orbits that limit both their orbital lifetime and consequences should a collision occur. NASA ARC has developed a concept for a highly-automated and distributed space traffic management (STM) architecture, drawing on similar work done to provide traffic management for small unmanned aerial systems (UAS) operating at low altitudes. The system proposes a strategy to accommodate growing space traffic volume safely, as well as pave the way for a transition of civil STM authority to a civilian governmental entity. The architecture envisions an open-access software platform architecture of data and service suppliers, consumers, and regulators, connected via a set of application programming interfaces (APIs). The platform would build on, rather than replicate existing integration and coordination efforts within the space situational awareness ecosystem, using existing standards for data message formats from organizations like the Consultative Committee for Space Data Systems and wrapping, rather than replacing existing integrations. We will present an initial STM architecture in this presentation, with a few examples showing how stakeholders can interact structurally, but flexibly, within this architecture.

Space Situational Awareness↗
NASA NTRS2020

Application of IRIG 106 Digital Data Recorder Standards for Flight Test

During flight tests, data is acquired from different sources and in different formats. Sensor data, aircraft avionics bus data, time, voice and video are essential for analysis of these flight tests. IRIG 106 standards exist for recording and transferring these data types. However, to enhance interoperability of flight test data between (multinational) test teams, a standard was needed to encapsulate all these data types. For this purpose the Telemetry Group of the Range Commanders Council (RCC) first published in 2004 the IRIG 106 Chapter 10 Standard, “Solid-State On-Board Recorder Standard”. This standard is evolving up to present. This AGARDograph gives an introduction to the standard, explains how the standard is positioned among other relevant standards, and describes the equipment and their application in flight tests with some examples. The topics covered include IRIG 106 Chapter 10 compatible recording of (multiple) data streams, synchronization of data, data recorders, data retrieval, data processing, and examples of flight test programs. Further development of the standard, originally published for on-board recorders, is described for extending the requirements for ground-based data recorders. The last chapter addresses a number of issues related to the application of the Chapter 10 standard with references to information and possible solutions. This document shows how data acquisition and data processing in accordance to IRIG 106 Chapter 10 standard can be applied in NATO flight tests and will thereby contribute to collaboration and cost efficiency.

flight test instrumentation↗
NASA NTRS2012

Improving Spacecraft Data Visualization Using Splunk

EPOXI, like all spacecraft missions, receives large volumes of telemetry data from its spacecraft, DIF. It is extremely important for this data to be updated quickly and presented in a readable manner so that the flight team can monitor the status of the spacecraft. Existing DMD pages for monitoring spacecraft telemetry, while functional, are limited and do not take advantage of modern search technology. For instance, they only display current data points from instruments on the spacecraft and have limited graphing capabilities, making it difficult to see historical data. The DMD pages have fixed refresh rates so the team must often wait several minutes to see the most recent data, even after it is received on the ground. The pages are also rigid and require an investment of time and money to update. To more easily organize and visualize spacecraft telemetry, the EPOXI team has begun experimenting with Splunk, a commercially-available data mining system. Splunk can take data received from the spacecraft's different data channels, often in different formats, and index all the data into a common format. Splunk allows flight team members to search through the different data formats from a single interface and to filter results by time range and data field to make finding specific spacecraft events quick and easy. Furthermore, Splunk provides functions to create custom interfaces which help team members visualize the data in charts and graphs to show how the health of the spacecraft has changed over time.One of the goals of my internship with my mentor, Victor Hwang, was to develop new Splunk interfaces to replace the DMD pages and give the spacecraft team access to historical data and visualizations that were previously unavailable. The specific requirements of these pages are discussed in the next section.

spacecraft missions↗
DOE OSTI2019

Generalized Interaction Data Interface and associated packages

GIDIplus contains libraries for reading and using GNDS-formatted nuclear data. It includes sub-packages GIDI, MCGIDI, PoPs, numerical Functions and status Message Reporting along with scripts for building and installing the entire library.

Beck, Bret↗
DOE OSTI2023

Python package for machine-readable access to PDG data (PDG Python API) v0.1

This Python package implements a high-level interface to access the data published by the Particle Data Group (PDG) in the Review of Particle Physics (the "Review"). The Particle Data Group is an international collaboration led by the PDG group at LBNL. The PDG summarizes the established knowledge in the field of particle physics in a single publication, the Review of Particle Physics. The Review is published and updated online (see https://pdg.lbl.gov) each year, and published in a scientific journal every other year. It is currently licensed under a CC BY-NC 4.0 license. In 2021 PDG was designated by the Office of Science as a SC PuRe Data Resource. The Review is one of the most highly cited publications in the field of particle physics. The PDG Python API is part of PDG's efforts to make all data provided in the Review available in machine-readable format. This data includes the PDG world averages (or best limits) on particle masses, widths or lifetimes, branching fractions, magnetic moments, form factors, coupling constant ratios, and searches, as well as particle quantum numbers. It also includes detailed information on how PDG arrived at its averages, such as e.g. tables of published measurements with comments and footnotes, information on the consistency of published measurements, and detailed fit information.

Beringer, Juerg↗
NASA NTRS1981

A statistical data analysis and plotting program for cloud microphysics experiments

The analysis software developed for atmospheric cloud microphysics experiments conducted in the laboratory as well as aboard a KC-135 aircraft is described. A group of four programs was developed and implemented on a Hewlett Packard 1000 series F minicomputer running under HP's RTE-IVB operating system. The programs control and read data from a MEMODYNE Model 3765-8BV cassette recorder, format the data on the Hewlett Packard disk subsystem, and generate statistical data (mean, variance, standard deviation) and voltage and engineering unit plots on a user selected plotting device. The programs are written in HP FORTRAN IV and HP ASSEMBLY Language with the graphics software using the HP 1000 Graphics. The supported plotting devices are the HP 2647A graphics terminal, the HP 9872B four color pen plotter, and the HP 2608A matrix line printer.

Jordan, A. J.↗
NASA NTRS1983

Beaufort/Bering 1979 microwave remote sensing data catalog report, 14-24 March 1979

The airborne microwave remote sending measurements obtained by the Langley Research Center in support of the 1979 Sea-Ice Radar Experiment (SIRE) in the Beaufort and Bering Seas are discussed. The remote sensing objective of SIRE was to define correlations between both active and passive microwave signatures and ice phenomena assocated with practical applications in the Arctic. The instruments used by Langley during SIRE include the stepped frequency microwave radiometer (SFMR), the airborne microwave scatterometer (AMSCAT), the precision radiation thermometer (PRT-5), and metric aerial photography. Remote sensing data are inventoried and cataloged in a user-friendly format. The data catalog is presented as time-history plots when and where data were obtained as well as the sensor configuration.

Hirstein, W. S.↗
DOE OSTI2015

Optimizing Geothermal Drilling: Oil and Gas Technology Transfer

There is a significant amount of financial risk associated with geothermal drilling. This study of drilling operations seeks opportunities to improve upon current practices and technologies. The scope of this study included analyzing 21 geothermal wells and 21 oil and gas wells. The goal was to determine a 'Perfect Well' using historical data to compare the best oil and gas well to the best geothermal well. Unfortunately, limitations encountered in the study included missing data (bit records, mud information, etc.) and poor data collection practices An online software database was used to format drilling data to IADC coded daily drilling reports and generate figures for analysis. Six major issues have been found in geothermal drilling operations. These problems include lost circulation, rig/ equipment selection, cementing, penetration rate, drilling program, and time management. As a result of these issues, geothermal drilling averaged 56.4 days longer than drilling comparable oil and gas wells in the wells in this study. Roughly $13.9 million was spent on non-productive time in the 21 geothermal wells, compared with only $1.3 million in the oil and gas wells, assuming a cost of $50,000 per day. Comparable events such as drilling the same sized hole, tripping in/out, cementing, and running the same size casing took substantially less time in the oil and gas wells. Geothermal wells were drilled using older and/or less advanced technology to depths less than 10,000 feet, while oil and gas wells reached 12,500 feet faster with purpose built rigs. A new approach is now underway that will optimize drilling programs throughout the drilling industry using Mechanical Specific Energy (MSE) as a tool to realize efficient drilling processes. Potential improvements for current geothermal operations are: the use of electronic records, real time services, and official glossary terms to describe rig operations, and advanced drilling rigs/technology.

15 GEOTHERMAL ENERGY↗
NASA NTRS2000

BOREAS RSS-16 AIRSAR CM Images: Integrated Processor Version 6.1 Level-3b

The BOREAS RSS-16 team used satellite and aircraft SAR data in conjunction with various ground measurements to determine the moisture regime of the boreal forest. RSS-16 assisted with the acquisition and ordering of NASA JPL AIRSAR data collected from the NASA DC-8 aircraft. The NASA JPL AIRSAR is a side-looking imaging radar system that utilizes the SAR principle to obtain high resolution images that represent the radar backscatter of the imaged surface at different frequencies and polarizations. The information contained in each pixel of the AIRSAR data represents the radar backscatter for all possible combinations of horizontal and vertical transmit and receive polarizations (i.e., HH, HV, VH, and VV). Geographically, the data cover portions of the BOREAS SSA and NSA. Temporally, the data were acquired from 12-Aug-1993 to 31-Jul-1995. The level-3b AIRSAR CM data are in compressed Stokes matrix format, which has 10 bytes per pixel. From this data format, it is possible to synthesize a number of different radar backscatter measurements. The data are stored in binary image-format files. The data files are available on a CD-ROM (see document number 20010000884), or from the Oak Ridge National Laboratory (ORNL) Distributed Active Archive Center (DAAC).

Hall, Forrest G.↗
NASA NTRS2013

Structural Dynamics and Data Analysis

This project consists of two parts, the first will be the post-flight analysis of data from a Delta IV launch vehicle, and the second will be a Finite Element Analysis of a CubeSat. Shock and vibration data was collected on WGS-5 (Wideband Global SATCOM- 5) which was launched on a Delta IV launch vehicle. Using CAM (CAlculation with Matrices) software, the data is to be plotted into Time History, Shock Response Spectrum, and SPL (Sound Pressure Level) curves. In this format the data is to be reviewed and compared to flight instrumentation data from previous flights of the same launch vehicle. This is done to ensure the current mission environments, such as shock, random vibration, and acoustics, are not out of family with existing flight experience. In family means the peaks on the SRS curve for WGS-5 are similar to the peaks from the previous flights and there are no major outliers. The curves from the data will then be compiled into a useful format so that is can be peer reviewed then presented before an engineering review board if required. Also, the reviewed data will be uploaded to the Engineering Review Board Information System (ERBIS) to archive. The second part of this project is conducting Finite Element Analysis of a CubeSat. In 2010, Merritt Island High School partnered with NASA to design, build and launch a CubeSat. The team is now called StangSat in honor of their mascot, the mustang. Over the past few years, the StangSat team has built a satellite and has now been manifested for flight on a SpaceX Falcon 9 launch in 2014. To prepare for the final launch, a test flight was conducted in Mojave, California. StangSat was launched on a Prospector 18D, a high altitude rocket made by Garvey Spacecraft Corporation, along with their sister satellite CP9 built by California Polytechnic University. However, StangSat was damaged during an off nominal landing and this project will give beneficial insights into what loads the CubeSat experienced during the crash. During the year, the MIHS students generated a SolidWorks (CAD software) geometry model of StangSat. This model will be imported into FEMAP (Finite Element Analysis (FEA) Software) and a finite element model wiiJ be created to predict the loads encountered during the crash of this rocket. This analysis will require learning how to import CAD models into the FEM, mesh and add constraints and concentrated masses to represent components inside the CubeSat frame, such as circuit boards, batteries and accelerometers. During the analysis the loads will be varied, in effort to duplicate the damage to the CubeSat. Results will then be peer reviewed and documented.

Luthman, Briana L.↗
NASA NTRS2018

GMI-IPS: Processing & Visualization Software Used in ATom DC-8 Aircraft Studies

NASA's Atmospheric Tomography Mission (ATom) deployed in each of the four seasons during 2016-2018, the DC-8 aircraft in order to establish global-scale datasets intended to improve the representation of chemically reactive gases in global atmospheric chemistry models (ACMs). The Global Modeling Initiative (GMI) executed simulations for each ATom flight using the GMI Chemistry Transport Model (GMI-CTM) to provide species concentrations of chemical gases along the DC-8 flight transects. To solve the problem of translating the GMI-CTM simulation data to the unique spatial resolutions of each ATom flight, the GMI ICARTT Processing Software (GMI-IPS) was developed.The GMI-IPS is written in Python and provides data processing, flight extraction, and visualization support for aircraft research projects using ICARTT format, which is a standard format for airborne instrument data. Additionally, the GMI-IPS interpolates global gridded model data from Hierarchical Data Format (HDF) to ICARTT compatible flight transects. Software classes for instruments and collections provided by the ATom DC-8 aircraft such as MER10, MMS, etc. are derived from a common base class. Other functionality provided by the GMI-IPS are: deriving missing flight entries along a transect, reading ICARTT entries from file, and providing Python data structures for storing flight and model information, and more.The GMI-IPS is GIT source controlled, has approximately 30,000 lines of code, and supports parallelization across data collections. It delivered GMI-CTM data for more than forty distinct DC-8 aircraft flights that took place under ATom. The output ICARTT files adhere to format standard V1.1, and pass the scan utility provided by NASA LaRC Airborne Science Data for Atmospheric Composition. This presentation will include a software and methods overview, and results from ATom, including assessments using the GMI-CTM showing how well observations from ATom flight transects represent a broader region.

Damon, M. R.↗