SEARCH · Search NASA

Results for “instrument data processing software”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 73 records · Page 4

All sources NASA NTRS DOE OSTI

NASA NTRS2014

Software Suite to Support In-Flight Characterization of Remote Sensing Systems

A characterization software suite was developed to facilitate NASA's in-flight characterization of commercial remote sensing systems. Characterization of aerial and satellite systems requires knowledge of ground characteristics, or ground truth. This information is typically obtained with instruments taking measurements prior to or during a remote sensing system overpass. Acquired ground-truth data, which can consist of hundreds of measurements with different data formats, must be processed before it can be used in the characterization. Accurate in-flight characterization of remote sensing systems relies on multiple field data acquisitions that are efficiently processed, with minimal error. To address the need for timely, reproducible ground-truth data, a characterization software suite was developed to automate the data processing methods. The characterization software suite is engineering code, requiring some prior knowledge and expertise to run. The suite consists of component scripts for each of the three main in-flight characterization types: radiometric, geometric, and spatial. The component scripts for the radiometric characterization operate primarily by reading the raw data acquired by the field instruments, combining it with other applicable information, and then reducing it to a format that is appropriate for input into MODTRAN (MODerate resolution atmospheric TRANsmission), an Air Force Research Laboratory-developed radiative transport code used to predict at-sensor measurements. The geometric scripts operate by comparing identified target locations from the remote sensing image to known target locations, producing circular error statistics defined by the Federal Geographic Data Committee Standards. The spatial scripts analyze a target edge within the image, and produce estimates of Relative Edge Response and the value of the Modulation Transfer Function at the Nyquist frequency. The software suite enables rapid, efficient, automated processing of ground truth data, which has been used to provide reproducible characterizations on a number of commercial remote sensing systems. Overall, this characterization software suite improves the reliability of ground-truth data processing techniques that are required for remote sensing system in-flight characterizations.

Stanley, Thomas↗

NASA NTRS1992

The ALEXIS data processing package: An IDL based system

The Array of Low Energy X-ray Imaging Sensors (ALEXIS) experiment consists of a mini-satellite containing six wide angle EUV/ultrasoft x-ray telescopes. Its purpose is to map out the sky in three narrow (approximately 5 percent) bandpasses around 66, 71, and 93 eV. The 66 and 71 eV bandpasses are centered on intense Fe emission lines which are characteristic of million degree plasmas such as the one thought to produce the soft x-ray background. The 93 eV bandpass is not near any strong emission lines and is more sensitive to continuum sources. The mission will be launched on the Pegasus Air Launched Vehicle in the second half of 1992 into a 400-nautical-mile, high inclination orbit and will be controlled entirely from a small ground station located at Los Alamos. The project is a collaborative effort between Los Alamos National Laboratory, Sandia National Laboratory, and the University of California-Berkeley Space Sciences Laboratory. The six telescopes are arranged in three pairs. As the satellite spins twice a minute they scan the entire anti-solar hemisphere. Each f/1 telescope consists of a spherical, multilayer-coated mirror with a curved, microchannel plate detector located at the prime focus. The multilayer coatings determine the bandpasses of the telescopes. The field of view of each telescope is 30 degrees with a spatial resolution of 0.5 degree, limited by spherical aberration. The data processing requirements for ALEXIS are large. Each event is one of the six telescopes is telemetered to the ground with its time of arrival and position on the detector. This information must be folded with the aspect solution for the satellite to reconstruct the direction on the sky from which the photon came. Because of the way the six telescopes scan the sky, the effective exposure calculation is also very computationally intensive. ALEXIS may generate up to 100 megabytes of raw data per day, which are converted into a gigabyte per day of processed data. While the processing job for ALEXIS is sizable, the programming staff is small. To maximize programming efficiency, and to make the best use of tools available in the public domain, we chose IDL as our software development platform. IDL was used from the start of instrument development through flight. We use IDL as a top-level executive for the processing tasks (replacing Unix shell scripts), as a device independent graphics engine, as a database manager, and as a final data manipulator. IDL routines spawn special purpose C programs to perform detailed telemetry deconvolution and other specialized functions. We discuss the use of IDL and C within the processing and archiving strategy for the ALEXIS data anlaysis system as implemented on a SPARCstation platform. We also show results from our End-to-End software simulation capability as processed by our analysis codes.

Bloch, J. J.↗

NASA NTRS2008

The Development of Point Doppler Velocimeter Data Acquisition and Processing Software

In order to develop efficient and quiet aircraft and validate Computational Fluid Dynamic predications, aerodynamic researchers require flow parameter measurements to characterize flow fields about wind tunnel models and jet flows. A one-component Point Doppler Velocimeter (pDv), a non-intrusive, laser-based instrument, was constructed using a design/develop/test/validate/deploy approach. A primary component of the instrument is software required for system control/management and data collection/reduction. This software along with evaluation algorithms, advanced pDv from a laboratory curiosity to a production level instrument. Simultaneous pDv and pitot probe velocity measurements obtained at the centerline of a flow exiting a two-inch jet, matched within 0.4%. Flow turbulence spectra obtained with pDv and a hot-wire detected the primary and secondary harmonics with equal dynamic range produced by the fan driving the flow. Novel,hardware and software methods were developed, tested and incorporated into the system to eliminate and/or minimize error sources and improve system reliability.

Cavone, Angelo A.↗

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.↗

NASA NTRS1996

Advanced Support Equipment For Remote Experiments

Advanced Carrier Customer Equipment Support System (ACCESS) is system of electronic communication and data-processing equipment for controlling remote scientific instruments and monitoring readings of instruments via telemetry. Designed to incorporate modular hardware and software making it adapable to other uses (including terrestrial ones) with minimal modifications.

Lui, Ben Y.↗

NASA NTRS2018

SpaceWire as a Cube-Sat Instrument Interface

SpaceWire is used in the control and data interface for an instrument on a pair of small satellites, one of which was launched in summer 2017. The instrument SpaceWire interface is implemented in a Field Programmable Gate Array as an instantiated core controlled by a LEON3FT CPU, which is also implemented as an instantiated core. The UT699 processor in the flight computer provides the spacecraft side’s SpaceWire interface. A simple message based protocol consisting of four message types was defined, based on existing SpaceWire standards. One was for passing commands to and responses from the instrument in the form of text strings similar to those from a system console where each line of text is passed in a SpaceWire message. Another was for passing spacecraft time to the instrument. The third was for transferring files using a subset of the Remote Memory Access Protocol (RMAP). The fourth was for retrieving science data from the instrument. A set of user application programming interface (API) routines provided an abstracted interface to both the serial console (used during debug) and the SpaceWire device interface. Early instrument development and testing was done with a set of utilities that controlled a Star-Dundee USB-SpaceWire brick providing a user interface similar to a serial console terminal emulator with the addition of file and data transfers. Later in the integration and test process, these utilities were integrated with the COSMOS ground systems software used for spacecraft control, providing a seamless transition from standalone instrument tests to benchtop flat-sat test and full spacecraft level tests.

Lux, James P.↗

NASA NTRS1993

Software metrics: The key to quality software on the NCC project

Network Control Center (NCC) Project metrics are captured during the implementation and testing phases of the NCCDS software development lifecycle. The metrics data collection and reporting function has interfaces with all elements of the NCC project. Close collaboration with all project elements has resulted in the development of a defined and repeatable set of metrics processes. The resulting data are used to plan and monitor release activities on a weekly basis. The use of graphical outputs facilitates the interpretation of progress and status. The successful application of metrics throughout the NCC project has been instrumental in the delivery of quality software. The use of metrics on the NCC Project supports the needs of the technical and managerial staff. This paper describes the project, the functions supported by metrics, the data that are collected and reported, how the data are used, and the improvements in the quality of deliverable software since the metrics processes and products have been in use.

Burns, Patricia J.↗

NASA NTRS2012

Photogrammetry Tool for Forensic Analysis

A system allows crime scene and accident scene investigators the ability to acquire visual scene data using cameras for processing at a later time. This system uses a COTS digital camera, a photogrammetry calibration cube, and 3D photogrammetry processing software. In a previous instrument developed by NASA, the laser scaling device made use of parallel laser beams to provide a photogrammetry solution in 2D. This device and associated software work well under certain conditions. In order to make use of a full 3D photogrammetry system, a different approach was needed. When using multiple cubes, whose locations relative to each other are unknown, a procedure that would merge the data from each cube would be as follows: 1. One marks a reference point on cube 1, then marks points on cube 2 as unknowns. This locates cube 2 in cube 1 s coordinate system. 2. One marks reference points on cube 2, then marks points on cube 1 as unknowns. This locates cube 1 in cube 2 s coordinate system. 3. This procedure is continued for all combinations of cubes. 4. The coordinate of all of the found coordinate systems is then merged into a single global coordinate system. In order to achieve maximum accuracy, measurements are done in one of two ways, depending on scale: when measuring the size of objects, the coordinate system corresponding to the nearest cube is used, or when measuring the location of objects relative to a global coordinate system, a merged coordinate system is used. Presently, traffic accident analysis is time-consuming and not very accurate. Using cubes with differential GPS would give absolute positions of cubes in the accident area, so that individual cubes would provide local photogrammetry calibration to objects near a cube.

Lane, John↗

NASA NTRS2000

Using XML and Java for Astronomical Instrumentation Control

Ames, Troy↗

NASA NTRS2015

Instrumentation & Data Acquisition System (D AS) Engineer

The primary job of an Instrumentation and Data Acquisition System (DAS) Engineer is to properly measure physical phenomenon of hardware using appropriate instrumentation and DAS equipment designed to record data during a specified test of the hardware. A DAS system includes a CPU or processor, a data storage device such as a hard drive, a data communication bus such as Universal Serial Bus, software to control the DAS system processes like calibrations, recording of data and processing of data. It also includes signal conditioning amplifiers, and certain sensors for specified measurements. My internship responsibilities have included testing and adjusting Pacific Instruments Model 9355 signal conditioning amplifiers, writing and performing checkout procedures, writing and performing calibration procedures while learning the basics of instrumentation.

Jackson, Markus Deon↗

NASA NTRS2001

Using XML and Java Technologies for Astronomical Instrument Control

Traditionally, instrument command and control systems have been highly specialized, consisting mostly of custom code that is difficult to develop, maintain, and extend. Such solutions are initially very costly and are inflexible to subsequent engineering change requests, increasing software maintenance costs. Instrument description is too tightly coupled with details of implementation. NASA Goddard Space Flight Center, under the Instrument Remote Control (IRC) project, is developing a general and highly extensible framework that applies to any kind of instrument that can be controlled by a computer. The software architecture combines the platform independent processing capabilities of Java with the power of the Extensible Markup Language (XML), a human readable and machine understandable way to describe structured data. A key aspect of the object-oriented architecture is that the software is driven by an instrument description, written using the Instrument Markup Language (IML), a dialect of XML. IML is used to describe the command sets and command formats of the instrument, communication mechanisms, format of the data coming from the instrument, and characteristics of the graphical user interface to control and monitor the instrument. The IRC framework allows the users to define a data analysis pipeline which converts data coming out of the instrument. The data can be used in visualizations in order for the user to assess the data in real-time, if necessary. The data analysis pipeline algorithms can be supplied by the user in a variety of forms or programming languages. Although the current integration effort is targeted for the High-resolution Airborne Wideband Camera (HAWC) and the Submillimeter and Far Infrared Experiment (SAFIRE), first-light instruments of the Stratospheric Observatory for Infrared Astronomy (SOFIA), the framework is designed to be generic and extensible so that it can be applied to any instrument. Plans are underway to test the framework with other types of instruments, such as remote sensing earth science instruments.

Ames, Troy↗

NASA NTRS2004

Position-Finding Instrument Built Around a Magnetometer

A coarse-positioning instrument is built around a three-axis magnetometer. The magnetometer is of a type that is made of inexpensive hardware and is suitable for use aboard spacecraft orbiting no more than 1,000 km above the surface of the Earth. A data processor programmed with suitable software and equipped with a central processing unit, random-access memory, programmable read-only memory, and interface circuitry for communication with external equipment are added to the basic magnetometer to convert it into a coarse-positioning instrument. Although the instrument was conceived for use aboard spacecraft, it could be useful for navigation on Earth under some circumstances. A major feature of the proposed instrument is an ability to generate a coarse estimate of its position in real time (that is, without start-up delay). Algorithms needed to solve the position equations have been developed. These include algorithms to work around gaps in measurement data that arise from a singularity near the minimum in the magnetic field of the Earth. Some work has been done to develop a prototype of this instrument incorporating a standard three-axis flux-gate magnetometer and a Pentium P-5 (or equivalent) processor with a clock frequency of 120 MHz. Alternatively, the processor could be of the 486 class. A computer model of the instrument has been completed and tested.

Ketchum, Eleanor↗

NASA NTRS2006

Progress in the Development of Practical Remote Detection of Icing Conditions

The NASA Icing Remote Sensing System (NIRSS) has been under definition and development at NASA Glenn Research Center since 1997. The goal of this development activity is to produce and demonstrate the required sensing and data processing technologies required to accurately remotely detect and measure icing conditions aloft. As part of that effort NASA has teamed with NCAR to develop software to fuse data from multiple instruments into a single detected icing condition product. The multiple instrument approach utilizes a X-band vertical staring radar, a multifrequency microwave, and a lidar ceilometer. The radar data determine cloud boundaries, the radiometer determines the sub-freezing temperature heights and total liquid water content, and the ceilometer refines the lower cloud boundary. Data is post-processed with a LabVIEW program with a resultant supercooled liquid water profile and aircraft hazard depiction. Ground-based, remotely-sensed measurements and in-situ measurements from research aircraft were gathered during the international 2003-2004 Alliance Icing Research Study (AIRS II). Comparisons between the remote sensing system s fused icing product and the aircraft measurements are reviewed here. While there are areas where improvement can be made, the cases examined suggest that the fused sensor remote sensing technique appears to be a valid approach.

Reehorst, Andrew↗

NASA NTRSDate not supplied

Making NASA GES DISC Level 2 Data GIS Analysis Ready

There are many valuable data hosted by NASA Goddard Earth Sciences Data and Information Services Center (GES DISC) for GIS applications in the areas of extreme weather events, climatic anomaly, and public health. However, using NASA Earth Science Data poses some challenges for GIS users. Many of these users are not experts in Earth Observation and have little knowledge about NASA's Earth science data. In the GIS community, GeoTiff is the most widely used raster format, whereas NASA's data is primarily in complex multidimensional netCDF and HDF formats. This complexity makes it difficult for GIS users, especially those who are unfamiliar with these formats. Although GIS software like ArcGIS has made progress in processing multidimensional netCDF data, certain issues still remain, particularly with level 2 data. In this study, we use TROPSpheric Monitoring instrument (TROPOMI) level 2 data as an example to demonstrate how to make such data GIS analysis ready. The process involves: 1. Creating a feature layer from the TROPOMI level 2 data. 2. Converting the feature layer to a gridded raster dataset. 3. Mosaicking gridded raster datasets into a raster dataset covering the entire desired extent. 4. Generating a symbology with a GIBS-specific style that aligns with the visual standards and requirements of GIBS. 5. Publishing image services. By performing these preprocessing and transformation steps, NASA level 2 data can be made compatible and ready for use within GIS software for various spatial analysis and visualization tasks.

Geographic Information System↗

NASA NTRS1985

NASA's Pilot Land Data System development program

The NASA Pilot Land Data System (PLDS) project is intended to enhance the effectiveness of data processing capabilities used by researchers applying remote sensing data in land science research. Two sites in the centerminous U.S. have been selected as study areas scanned by Landsat, Nimbus and GOES instruments. The data will be analyzed by teams of researchers representing different fields of expertise. The PLDS program will explore data management, networking and communications, system access capabilities, land analysis software, special processes and overall systems engineerng. The data will be processed by researchers working interactively through remote supermicrocomputer workstations using a variety of operating systems and on-site software capabilities.

Price, R. D.↗

NASA NTRS2001

ICESat (GLAS) Science Processing Software Document Series: GLAS Science Software Requirements Document - Volume 3

This document addresses the software requirements of the Geoscience Laser Altimeter System (GLAS) Standard Data Software (SDS) supporting the GLAS instrument on the EOS ICESat Spacecraft. This Software Requirements Document represents the initial collection of the technical engineering information for the GLAS SDS. This information is detailed within the second of four main volumes of the Standard documentation, the Product Specification volume. This document is a "roll-out" from the governing volume outline containing the Concept and Requirements sections.

Jester, Peggy L.↗

NASA NTRS2011

Virtual Sensor Test Instrumentation

Virtual Sensor Test Instrumentation is based on the concept of smart sensor technology for testing with intelligence needed to perform sell-diagnosis of health, and to participate in a hierarchy of health determination at sensor, process, and system levels. A virtual sensor test instrumentation consists of five elements: (1) a common sensor interface, (2) microprocessor, (3) wireless interface, (4) signal conditioning and ADC/DAC (analog-to-digital conversion/ digital-to-analog conversion), and (5) onboard EEPROM (electrically erasable programmable read-only memory) for metadata storage and executable software to create powerful, scalable, reconfigurable, and reliable embedded and distributed test instruments. In order to maximize the efficient data conversion through the smart sensor node, plug-and-play functionality is required to interface with traditional sensors to enhance their identity and capabilities for data processing and communications. Virtual sensor test instrumentation can be accessible wirelessly via a Network Capable Application Processor (NCAP) or a Smart Transducer Interlace Module (STIM) that may be managed under real-time rule engines for mission-critical applications. The transducer senses the physical quantity being measured and converts it into an electrical signal. The signal is fed to an A/D converter, and is ready for use by the processor to execute functional transformation based on the sensor characteristics stored in a Transducer Electronic Data Sheet (TEDS). Virtual sensor test instrumentation is built upon an open-system architecture with standardized protocol modules/stacks to interface with industry standards and commonly used software. One major benefit for deploying the virtual sensor test instrumentation is the ability, through a plug-and-play common interface, to convert raw sensor data in either analog or digital form, to an IEEE 1451 standard-based smart sensor, which has instructions to program sensors for a wide variety of functions. The sensor data is processed in a distributed fashion across the network, providing a large pool of resources in real time to meet stringent latency requirements.

Wang, Roy↗

NASA NTRS1975

Data management for Large Space Telescope

The data management system for the Large Space Telescope (LST) must be capable of meeting requirements of 160 million bits per 95 min orbit with a bit error rate of less than 0.00001 for data. The system will be supported by the Tracking and Data Relay Satellite System of the Space Tracking and Data Network. The on-board system includes a general purpose computer that controls the vehicle as a stable observation platform and the array of instruments used for data collection. The ground-based system comprises a Mission Operations Center (MOC), a Science Institute where instrument data is processed, and a communications service for the space and point-to-point data flow. The allocation of hardware and software between on-board and ground-based components to achieve design objectives of maximum flexibility at minimum cost is discussed.

Hope, G. R., Jr.↗