Search NASA⌕ Search

SEARCH · Search NASA

Results for “Graphical User Interface (GUI)”

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 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

Remote Sensing Time Series Product Tool

The TSPT (Time Series Product Tool) software was custom-designed for NASA to rapidly create and display single-band and band-combination time series, such as NDVI (Normalized Difference Vegetation Index) images, for wide-area crop surveillance and for other time-critical applications. The TSPT, developed in MATLAB, allows users to create and display various MODIS (Moderate Resolution Imaging Spectroradiometer) or simulated VIIRS (Visible/Infrared Imager Radiometer Suite) products as single images, as time series plots at a selected location, or as temporally processed image videos. Manually creating these types of products is extremely labor intensive; however, the TSPT development tool makes the process simplified and efficient. MODIS is ideal for monitoring large crop areas because of its wide swath (2330 km), its relatively small ground sample distance (250 m), and its high temporal revisit time (twice daily). Furthermore, because MODIS imagery is acquired daily, rapid changes in vegetative health can potentially be detected. The new TSPT technology provides users with the ability to temporally process high-revisit-rate satellite imagery, such as that acquired from MODIS and from its successor, the VIIRS. The TSPT features the important capability of fusing data from both MODIS instruments onboard the Terra and Aqua satellites, which drastically improves cloud statistics. With the TSPT, MODIS metadata is used to find and optionally remove bad and suspect data. Noise removal and temporal processing techniques allow users to create low-noise time series plots and image videos and to select settings and thresholds that tailor particular output products. The TSPT GUI (graphical user interface) provides an interactive environment for crafting what-if scenarios by enabling a user to repeat product generation using different settings and thresholds. The TSPT Application Programming Interface provides more fine-tuned control of product generation, allowing experienced programmers to bypass the GUI and to create more user-specific output products, such as comparison time plots or images. This type of time series analysis tool for remotely sensed imagery could be the basis of a large-area vegetation surveillance system. The TSPT has been used to generate NDVI time series over growing seasons in California and Argentina and for hurricane events, such as Hurricane Katrina.

Predos, Don↗
NASA NTRS2003

XML-Based Generator of C++ Code for Integration With GUIs

An open source computer program has been developed to satisfy a need for simplified organization of structured input data for scientific simulation programs. Typically, such input data are parsed in from a flat American Standard Code for Information Interchange (ASCII) text file into computational data structures. Also typically, when a graphical user interface (GUI) is used, there is a need to completely duplicate the input information while providing it to a user in a more structured form. Heretofore, the duplication of the input information has entailed duplication of software efforts and increases in susceptibility to software errors because of the concomitant need to maintain two independent input-handling mechanisms. The present program implements a method in which the input data for a simulation program are completely specified in an Extensible Markup Language (XML)-based text file. The key benefit for XML is storing input data in a structured manner. More importantly, XML allows not just storing of data but also describing what each of the data items are. That XML file contains information useful for rendering the data by other applications. It also then generates data structures in the C++ language that are to be used in the simulation program. In this method, all input data are specified in one place only, and it is easy to integrate the data structures into both the simulation program and the GUI. XML-to-C is useful in two ways: 1. As an executable, it generates the corresponding C++ classes and 2. As a library, it automatically fills the objects with the input data values.

Hua, Hook↗
NASA NTRS1991

Transportable Applications Environment (TAE) Plus: A NASA tool for building and managing graphical user interfaces

The Transportable Applications Environment (TAE) Plus, developed at GSFC, is an advanced portable user interface development environment which simplifies the process of creating and managing complex application graphical user interfaces (GUI's), supports prototyping, allows applications to be ported easily between different platforms and encourages appropriate levels of user interface consistency between applications. The following topics are discussed: the capabilities of the TAE Plus tool; how the implementation has utilized state-of-the-art technologies within graphic workstations; and how it has been used both within and outside of NASA.

Szczur, Martha R.↗
NASA NTRS2012

User's Guide for the Commercial Modular Aero-Propulsion System Simulation (C-MAPSS): Version 2

This report is a Users Guide for version 2 of the NASA-developed Commercial Modular Aero-Propulsion System Simulation (C-MAPSS) software, which is a transient simulation of a large commercial turbofan engine (up to 90,000-lb thrust) with a realistic engine control system. The software supports easy access to health, control, and engine parameters through a graphical user interface (GUI). C-MAPSS v.2 has some enhancements over the original, including three actuators rather than one, the addition of actuator and sensor dynamics, and an improved controller, while retaining or improving on the convenience and user-friendliness of the original. C-MAPSS v.2 provides the user with a graphical turbofan engine simulation environment in which advanced algorithms can be implemented and tested. C-MAPSS can run user-specified transient simulations, and it can generate state-space linear models of the nonlinear engine model at an operating point. The code has a number of GUI screens that allow point-and-click operation, and have editable fields for user-specified input. The software includes an atmospheric model which allows simulation of engine operation at altitudes from sea level to 40,000 ft, Mach numbers from 0 to 0.90, and ambient temperatures from -60 to 103 F. The package also includes a power-management system that allows the engine to be operated over a wide range of thrust levels throughout the full range of flight conditions.

Liu, Yuan↗
NASA NTRS2012

Assessing Upper-Level Winds on Day-of-Launch

On the day-or-launch. the 45th Weather Squadron Launch Weather Officers (LWOS) monitor the upper-level winds for their launch customers to include NASA's Launch Services Program (LSP). During launch operations, the payload launch team sometimes asks the LWO if they expect the upper level winds to change during the countdown but the LWOs did not have the capability to quickly retrieve or display the upper-level observations and compare them to the numerical weather prediction model point forecasts. The LWOs requested the Applied Meteorology Unit (AMU) develop a capability in the form of a graphical user interface (GUI) that would allow them to plot upper-level wind speed and direction observations from the Kennedy Space Center Doppler Radar Wind Profilers and Cape Canaveral Air Force Station rawinsondes and then overlay model point forecast profiles on the observation profiles to assess the performance of these models and graphically display them to the launch team. The AMU developed an Excel-based capability for the LWOs to assess the model forecast upper-level winds and compare them to observations. They did so by creating a GUI in Excel that allows the LWOs to first initialize the models by comparing the O-hour model forecasts to the observations and then to display model forecasts in 3-hour intervals from the current time through 12 hours.

Bauman, William H., III↗
NASA NTRS1995

TADS: A CFD-based turbomachinery and analysis design system with GUI. Volume 1: Method and results

The primary objective of this study was the development of a CFD (Computational Fluid Dynamics) based turbomachinery airfoil analysis and design system, controlled by a GUI (Graphical User Interface). The computer codes resulting from this effort are referred to as TADS (Turbomachinery Analysis and Design System). This document is the Final Report describing the theoretical basis and analytical results from the TADS system, developed under Task 18 of NASA Contract NAS3-25950, ADPAC System Coupling to Blade Analysis & Design System GUI. TADS couples a throughflow solver (ADPAC) with a quasi-3D blade-to-blade solver (RVCQ3D) in an interactive package. Throughflow analysis capability was developed in ADPAC through the addition of blade force and blockage terms to the governing equations. A GUI was developed to simplify user input and automate the many tasks required to perform turbomachinery analysis and design. The coupling of the various programs was done in such a way that alternative solvers or grid generators could be easily incorporated into the TADS framework. Results of aerodynamic calculations using the TADS system are presented for a highly loaded fan, a compressor stator, a low speed turbine blade and a transonic turbine vane.

Topp, D. A.↗
NASA NTRS2017

Evaluation of the Next-Gen Exercise Software Interface in the NEEMO Analog

NSBRI (National Space Biomedical Research Institute) funded research grant to develop the 'NextGen' exercise software for the NEEMO (NASA Extreme Environment Mission Operations) analog. Develop a software architecture to integrate instructional, motivational and socialization techniques into a common portal to enhance exercise countermeasures in remote environments. Increase user efficiency and satisfaction, and institute commonality across multiple exercise systems. Utilized GUI (Graphical User Interface) design principals focused on intuitive ease of use to minimize training time and realize early user efficiency. Project requirement to test the software in an analog environment. Top Level Project Aims: 1) Improve the usability of crew interface software to exercise CMS (Crew Management System) through common app-like interfaces. 2) Introduce virtual instructional motion training. 3) Use virtual environment to provide remote socialization with family and friends, improve exercise technique, adherence, motivation and ultimately performance outcomes.

Hanson, Andrea↗
NASA NTRS1994

A software architecture for automating operations processes

The Operations Engineering Lab (OEL) at JPL has developed a software architecture based on an integrated toolkit approach for simplifying and automating mission operations tasks. The toolkit approach is based on building adaptable, reusable graphical tools that are integrated through a combination of libraries, scripts, and system-level user interface shells. The graphical interface shells are designed to integrate and visually guide a user through the complex steps in an operations process. They provide a user with an integrated system-level picture of an overall process, defining the required inputs and possible output through interactive on-screen graphics. The OEL has developed the software for building these process-oriented graphical user interface (GUI) shells. The OEL Shell development system (OEL Shell) is an extension of JPL's Widget Creation Library (WCL). The OEL Shell system can be used to easily build user interfaces for running complex processes, applications with extensive command-line interfaces, and tool-integration tasks. The interface shells display a logical process flow using arrows and box graphics. They also allow a user to select which output products are desired and which input sources are needed, eliminating the need to know which program and its associated command-line parameters must be executed in each case. The shells have also proved valuable for use as operations training tools because of the OEL Shell hypertext help environment. The OEL toolkit approach is guided by several principles, including the use of ASCII text file interfaces with a multimission format, Perl scripts for mission-specific adaptation code, and programs that include a simple command-line interface for batch mode processing. Projects can adapt the interface shells by simple changes to the resources configuration file. This approach has allowed the development of sophisticated, automated software systems that are easy, cheap, and fast to build. This paper will discuss our toolkit approach and the OEL Shell interface builder in the context of a real operations process example. The paper will discuss the design and implementation of a Ulysses toolkit for generating the mission sequence of events. The Sequence of Events Generation (SEG) system provides an adaptable multimission toolkit for producing a time-ordered listing and timeline display of spacecraft commands, state changes, and required ground activities.

Miller, Kevin J.↗
NASA NTRS2004

Glenn Heat Transfer Simulation and Solver Graphical User Interface: Development and Testing

In the Tui ine Branch of the Turbomachinery and Propulsion Systems Division, researching and developing efficient turbine aerothermodynamics technologies is the main objective. Creating effective turbines for jet engines is a process which, if based purely on physical experimental testing, would be extremely expensive. It is for this reason, and also for the reasons of speed and ease, that the Turbine Branch spends a large amount of effort working with simulations of turbines. Specifically, they focus their work on two main fields: Computational Field Dynamics (CFD), and Experimental data analysis. The experimental field involves comparing experimental results to simulated results, whereas the CFD field involves running these simulations. The simulations are applied to aerodynamics and heat transfer cases, for both steady and unsteady flow conditions. By and large this work is applied to the domain of flow and heat transfer in axial turbines. The main application used to run these heat flow simulations is GlennHT. This program, recently rewritten in FORTRAN 90, allows the user to input a job file which specifies all the necessary parameters needed to simulate flow through a user-defined grid. There are several other executables used as well, ranging in application from converting grid files to and from particular formats, to merging blocks in a connectivity file, to converting connectivity files to a GlennHT compatible format. All of these executables are run from the command line in a terminal; some of them have interactive prompts where the user must specify the files to be manipulated after the program starts, while others take all of their parameters from the command line. With this amount of variation comes a good deal of commands and formats to memorize, which can cause slower and less efficient work, as users may forget how to execute a certain program, or not remember the pathnames of the files they wish to use. Two years ago, steps were made to expedite this process with a graphical user interface (GUI) that combines the functionality of all the executables along with adding some new functionality, such as residuals graphing and boundary conditions creation. Upon my beginning here at Glenn, many parts of the GUI, which was developed in Java, were nonfunctional. There were also issues with cross-platforming, as systems in the branch were transitioning from Silicon Graphics (SGI) machines to Linux machines. My goals this summer are to finish the parts of the GUI that are not yet completed, fix parts that did not work correctly, expand the functionality to include other useful features, such as grid surface highlighting, and make the system compatible with both Linux and SGI. I will also be heavily testing the system and providing sufficient documentation on how to use the GUI, as no such documentation existed previously.

Kardamis, Joseph R.↗
NASA NTRS2022

Real-Time Exposure Control and Instrument Operation With the NEID Spectrograph GUI

The NEID spectrograph on the WIYN 3.5-m telescope at Kitt Peak has completed its first full year of science operations and is reliably delivering sub-m/s precision radial velocity measurements. The NEID instrument control system uses the TIMS package (Bender et al. 2016), which is a client-server software system built around the twisted python software stack. During science observations, interaction with the NEID spectrograph is handled through a pair of graphical user interfaces (GUIs), written in PyQT, which wrap the underlying instrument control software and provide straightforward and reliable access to the instrument. Here, we detail the design of these interfaces and present an overview of their use for NEID operations. Observers can use the NEID GUIs to set the exposure time, signal-to-noise ratio (SNR) threshold, and other relevant parameters for observations, configure the calibration bench and observing mode, track or edit observation metadata, and monitor the current state of the instrument. These GUIs facilitate automatic spectrograph configuration and target ingestion from the nightly observing queue, which improves operational efficiency and consistency across epochs. By interfacing with the NEID exposure meter, the GUIs also allow observers to monitor the progress of individual exposures and trigger the shutter on user-defined SNR thresholds. In addition, inset plots of the instantaneous and cumulative exposure meter counts as each observation progresses allow for rapid diagnosis of changing observing conditions as well as guiding failure and other emergent issues.

Arvind F Gupta↗
NASA NTRS2010

PLOT3D Export Tool for Tecplot

The PLOT3D export tool for Tecplot solves the problem of modified data being impossible to output for use by another computational science solver. The PLOT3D Exporter add-on enables the use of the most commonly available visualization tools to engineers for output of a standard format. The exportation of PLOT3D data from Tecplot has far reaching effects because it allows for grid and solution manipulation within a graphical user interface (GUI) that is easily customized with macro language-based and user-developed GUIs. The add-on also enables the use of Tecplot as an interpolation tool for solution conversion between different grids of different types. This one add-on enhances the functionality of Tecplot so significantly, it offers the ability to incorporate Tecplot into a general suite of tools for computational science applications as a 3D graphics engine for visualization of all data. Within the PLOT3D Export Add-on are several functions that enhance the operations and effectiveness of the add-on. Unlike Tecplot output functions, the PLOT3D Export Add-on enables the use of the zone selection dialog in Tecplot to choose which zones are to be written by offering three distinct options - output of active, inactive, or all zones (grid blocks). As the user modifies the zones to output with the zone selection dialog, the zones to be written are similarly updated. This enables the use of Tecplot to create multiple configurations of a geometry being analyzed. For example, if an aircraft is loaded with multiple deflections of flaps, by activating and deactivating different zones for a specific flap setting, new specific configurations of that aircraft can be easily generated by only writing out specific zones. Thus, if ten flap settings are loaded into Tecplot, the PLOT3D Export software can output ten different configurations, one for each flap setting.

Alter, Stephen↗
NASA NTRS2006

X-Windows PVT Widget Class

The X-Windows Process Validation Table (PVT) Widget Class ( Class is used here in the object-oriented-programming sense of the word) was devised to simplify the task of implementing network registration services for Information Sharing Protocol (ISP) graphical-user-interface (GUI) computer programs. Heretofore, ISP PVT programming tasks have required many method calls to identify, query, and interpret the connections and messages exchanged between a client and a PVT server. Normally, programmers have utilized direct access to UNIX socket libraries to implement the PVT protocol queries, necessitating the use of many lines of source code to perform frequent tasks. Now, the X-Windows PVT Widget Class encapsulates ISP client server network registration management tasks within the framework of an X Windows widget. Use of the widget framework enables an X Windows GUI program to interact with PVT services in an abstract way and in the same manner as that of other graphical widgets, making it easier to program PVT clients. Wrapping the PVT services inside the widget framework enables a programmer to treat a PVT server interface as though it were a GUI. Moreover, an alternate subclass could implement another service in a widget of the same type. This program was written by Matthew R. Barry of United Space Alliance for Johnson Space Center. For further information, contact the Johnson Technology Transfer Office at (281) 483-3809. MSC-23582 Shuttle Data Center File- Processing Tool in Java A Java-language computer program has been written to facilitate mining of data in files in the Shuttle Data Center (SDC) archives. This program can be executed on a variety of workstations or via Web-browser programs. This program is partly similar to prior C-language programs used for the same purpose, while differing from those programs in that it exploits the platform-neutrality of Java in implementing several features that are important for analysis of large sets of time-series data. The program supports regular expression queries of SDC archive files, reads the files, interleaves the time-stamped samples according to a chosen output, then transforms the results into that format. A user can choose among a variety of output file formats that are useful for diverse purposes, including plotting, Markov modeling, multivariate density estimation, and wavelet multiresolution analysis, as well as for playback of data in support of simulation and testing.

Barry, Matthew R.↗
NASA NTRS1998

A Geometry Based Infra-Structure for Computational Analysis and Design

The computational steps traditionally taken for most engineering analysis suites (computational fluid dynamics (CFD), structural analysis, heat transfer and etc.) are: (1) Surface Generation -- usually by employing a Computer Assisted Design (CAD) system; (2) Grid Generation -- preparing the volume for the simulation; (3) Flow Solver -- producing the results at the specified operational point; (4) Post-processing Visualization -- interactively attempting to understand the results. For structural analysis, integrated systems can be obtained from a number of commercial vendors. These vendors couple directly to a number of CAD systems and are executed from within the CAD Graphical User Interface (GUI). It should be noted that the structural analysis problem is more tractable than CFD; there are fewer mesh topologies used and the grids are not as fine (this problem space does not have the length scaling issues of fluids). For CFD, these steps have worked well in the past for simple steady-state simulations at the expense of much user interaction. The data was transmitted between phases via files. In most cases, the output from a CAD system could go to Initial Graphics Exchange Specification (IGES) or Standard Exchange Program (STEP) files. The output from Grid Generators and Solvers do not really have standards though there are a couple of file formats that can be used for a subset of the gridding (i.e. PLOT3D data formats). The user would have to patch up the data or translate from one format to another to move to the next step. Sometimes this could take days. Specifically the problems with this procedure are:(1) File based -- Information flows from one step to the next via data files with formats specified for that procedure. File standards, when they exist, are wholly inadequate. For example, geometry from CAD systems (transmitted via IGES files) is defined as disjoint surfaces and curves (as well as masses of other information of no interest for the Grid Generator). This is particularly onerous for modern CAD systems based on solid modeling. The part was a proper solid and in the translation to IGES has lost this important characteristic. STEP is another standard for CAD data that exists and supports the concept of a solid. The problem with STEP is that a solid modeling geometry kernel is required to query and manipulate the data within this type of file. (2) 'Good' Geometry. A bottleneck in getting results from a solver is the construction of proper geometry to be fed to the grid generator. With 'good' geometry a grid can be constructed in tens of minutes (even with a complex configuration) using unstructured techniques. Adroit multi-block methods are not far behind. This means that a million node steady-state solution can be computed on the order of hours (using current high performance computers) starting from this 'good' geometry. Unfortunately, the geometry usually transmitted from the CAD system is not 'good' in the grid generator sense. The grid generator needs smooth closed solid geometry. It can take a week (or more) of interaction with the CAD output (sometimes by hand) before the process can begin. One way Communication. (3) One-way Communication -- All information travels on from one phase to the next. This makes procedures like node adaptation difficult when attempting to add or move nodes that sit on bounding surfaces (when the actual surface data has been lost after the grid generation phase). Until this process can be automated, more complex problems such as multi-disciplinary analysis or using the above procedure for design becomes prohibitive. There is also no way to easily deal with this system in a modular manner. One can only replace the grid generator, for example, if the software reads and writes the same files. Instead of the serial approach to analysis as described above, CAPRI takes a geometry centric approach. This makes the actual geometry (not a discretized version) accessible to all phases of the analysis. The connection to the geometry is made through an Application Programming Interface (API) and NOT a file system. This API isolates the top-level applications (grid generators, solvers and visualization components) from the geometry engine. Also this allows the replacement of one geometry kernel with another, without effecting these top-level applications. For example, if UniGraphics is used as the CAD package then Parasolid (UG's own geometry engine) can be used for all geometric queries so that no solid geometry information is lost in a translation. This is much better than STEP because when the data is queried, the same software is executed as used in the CAD system. Therefore, one analyzes the exact part that is in the CAD system. CAPRI uses the same idea as the commercial structural analysis codes but does not specify control. Software components of the CAD system are used, but the analysis suite, not the CAD operator, specifies the control of the software session. This also means that the license issues (may be) minimized and individuals need not have to know how to operate a CAD system in order to run the suite.

Haimes, Robert↗
NASA NTRS2008

JAVA Stereo Display Toolkit

This toolkit provides a common interface for displaying graphical user interface (GUI) components in stereo using either specialized stereo display hardware (e.g., liquid crystal shutter or polarized glasses) or anaglyph display (red/blue glasses) on standard workstation displays. An application using this toolkit will work without modification in either environment, allowing stereo software to reach a wider audience without sacrificing high-quality display on dedicated hardware. The toolkit is written in Java for use with the Swing GUI Toolkit and has cross-platform compatibility. It hooks into the graphics system, allowing any standard Swing component to be displayed in stereo. It uses the OpenGL graphics library to control the stereo hardware and to perform the rendering. It also supports anaglyph and special stereo hardware using the same API (application-program interface), and has the ability to simulate color stereo in anaglyph mode by combining the red band of the left image with the green/blue bands of the right image. This is a low-level toolkit that accomplishes simply the display of components (including the JadeDisplay image display component). It does not include higher-level functions such as disparity adjustment, 3D cursor, or overlays all of which can be built using this toolkit.

Edmonds, Karina↗
NASA NTRSDate not supplied

RadLab: A Comprehensive Database and Graphical and Programming Interfaces for Biologically Relevant Space Radiation Data

RadLab, a new component of the NASA Open Science Data Repository (OSDR), is a platform built upon a database of radiation data relevant to space biology. RadLab provides visual and programmatic interfaces for interrogation of its database, as well as a submission process for inclusion of data from investigators. The RadLab application programming interface (API) implements a request syntax enabling users to retrieve data filtered by various combinations of parameters (detector type, location, direction, timespan, etc), which are delivered in machine-readable text formats, ready to be ingested by downstream analysis pipelines; while the graphical user interface (GUI) provides easy means to iteratively modify query parameters and incorporates a number of standard analyses and visualizations (time series plots, geospatial visualizations, detector comparison). Investigators from many countries, including US, Russia, Japan, Canada, the Czech Republic, Germany, Hungary, and Italy, have committed to provide data from their instruments located on the ISS; RadLab will also include data from other spacecraft in LEO (e.g., the Space Shuttle, the Mir space station), BLEO (e. g. BioSentinel, Mars Orbiter, among others), and on other celestial bodies (e. g. Chang’e 4, Curiosity). The first release of RadLab has been made available to the public. Once fully operational, RadLab will provide a comprehensive and ever-growing compendium of space radiation data, facilitating straightforward access to multiple types of readings and enabling space biology researchers to perform intercomparisons of detectors and to determine the radiation environment of research missions, both via programmatic retrieval of these data and via the graphical analysis toolkit; as well as a user-friendly submission portal for ingesting data from space agencies and research institutions. Radiation scientists will be able to use RadLab to gain a deeper understanding of the space radiation environment for future human space exploration. The RadLab Working Group has been formed to foster close collaborations among data contributors and users, to identify data sources, to put in place standards for data normalization, to guide the development of features of the analysis toolkit, to establish the use of RadLab in space radiation biology research, and eventually to provide a forum for discussing relevant research issues that can take advantage of RadLab's capabilities.

radiation↗
NASA NTRSDate not supplied

RadLab: A Comprehensive Database and Graphical and Programming Interfaces for Biologically Relevant Space Radiation Data

RadLab, a new component of the NASA Open Science Data Repository (OSDR), comprises a database of radiation measurements relevant to space biology, and visual and programmatic interfaces for interrogation and retrieval of these data. The attributes of data available through RadLab include spacecraft, types of radiation sensing instruments, locations within the spacecraft (e.g. modules of the ISS), associated celestial bodies, trajectories, and spacecraft coordinates. The application programming interface (API) implements a request syntax for retrieval of timestamped data filtered by various combinations of such attributes; the graphical user interface (GUI) extends this functionality with visualizations, such as spacecraft schematics, time series plots, geospatial visualizations, and provides easy means to iteratively refine search parameters, inspect the data on the fly, and download target subsets of these data. The release of RadLab currently available to the public contains datasets provided by US and international collaborators and focuses on data recorded on the ISS. Investigators from multiple countries, including the US, Canada, Germany, Bulgaria, Hungary, Italy, Japan, Russia and the Czech Republic, have committed to provide data from their instruments in and beyond low Earth orbit; RadLab will also soon expand to include past (e.g. Shuttle and Mir) and future (e.g. Artemis) data. RadLab will provide a comprehensive, dynamic compendium of space radiation data, enabling the scientific community to perform analyses of data from multiple detectors and to determine the radiation environment of research missions and experiments, both via programmatic retrieval of these data and through the graphical analysis toolkit. The RadLab Working Group has been formed to foster collaborations among data contributors and users, to identify data sources, to put in place standards for data harmonization, and to guide the development of the platform, with the goal to establish the use of RadLab in space radiation research and to advance our understanding of the space radiation environment in human habitats.

radiation↗
NASA NTRS2000

Digital Channel Simulator Developed and Tested

The Digital Channel Simulator (DCS) is a real-time test set developed in-house by the NASA Glenn Research Center at Lewis Field that simulates the characteristics of the modulator, demodulator, and transmission medium in a typical communications system to enable controlled laboratory testing of codec pairs. The DCS can support data rates up to 100 megasymbols per second (Msymbols/sec) with symbol sizes up to 10 bits and is compatible with both TTL (transistor transistor logic) and ECL (emitter coupled logic) interfaces. Because of its use of digital integrated circuits (IC's), the DCS offers the user accurate and repeatable testing while maintaining a simple reconfiguration of the modulation scheme and noise characteristics. The PC-based graphical user interface (GUI) assures user friendly operation for configuring, controlling, and monitoring the DCS and system during tests. In a typical communications system, the modulator places a symbol in constellation space and puts it on a carrier to be sent to the demodulator. Because of noise on the channel, the I and Q position in constellation space cannot be recovered exactly, and the received coordinates shift. To mimic this process in the laboratory, the DCS uses a mapper to place the symbol in constellation space. It simulates the shift in coordinates by digitally adding "noise" to the I and Q values. The mapper and noise source are implemented in lookup tables. Modulation schemes and noise characteristics are set by the values loaded in these tables. The mapper also has a pass-through mode to facilitate modulator testing, allowing noise to be added to 8-bit I and Q values of modulated data without a second mapping. To achieve high symbol rates, eight processing circuits are placed in parallel between an ECL demultiplexer and multiplexer. A graphical user interface was developed to calculate, load, and verify the values for the lookup tables. This interface can also be used to debug and verify proper operation of the channel simulator or to control an experiment. Operation of the DCS has been verified through three tests: a low-speed comprehensive system test, a high-speed (20 Msymbols/sec) test of the TTL interface, and a high-speed (100 Msymbols/sec) test of the ECL interface. The DCS is now ready for use by NASA and external customers.

Bizon, Thomas P.↗
NASA NTRS2006

X-Windows Socket Widget Class

The X-Windows Socket Widget Class ("Class" is used here in the object-oriented-programming sense of the word) was devised to simplify the task of implementing network connections for graphical-user-interface (GUI) computer programs. UNIX Transmission Control Protocol/Internet Protocol (TCP/IP) socket programming libraries require many method calls to configure, operate, and destroy sockets. Most X Windows GUI programs use widget sets or toolkits to facilitate management of complex objects. The widget standards facilitate construction of toolkits and application programs. The X-Windows Socket Widget Class encapsulates UNIX TCP/IP socket-management tasks within the framework of an X Windows widget. Using the widget framework, X Windows GUI programs can treat one or more network socket instances in the same manner as that of other graphical widgets, making it easier to program sockets. Wrapping ISP socket programming libraries inside a widget framework enables a programmer to treat a network interface as though it were a GUI.

Barry, Matthew R.↗