Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “telemetry”

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 973 records · Page 54
All sourcesNASA NTRSDOE OSTI
NASA NTRS1978

Patient Monitoring

In photo above, the electrocardiogram of a hospitalized patient is being transmitted by telemetry. Widely employed in space operations, telemetry is a process wherein instrument data is converted to electrical signals and sent to a receiver where the signals are reconverted to usable information. In this instance, heart readings are picked up by the electrode attached to the patient's body and delivered by wire to the small box shown, which is a telemetry transmitter. The signals are relayed wirelessly to the console in the background, which converts them to EKG data. The data is displayed visually and recorded on a printout; at the same time, it is transmitted to a central control station (upper photo) where a nurse can monitor the condition of several patients simultaneously. The Patient Monitoring System was developed by SCI Systems, Inc., Huntsville, Alabama, in conjunction with Abbott Medical Electronics, Houston, Texas. In developing the system, SCI drew upon its extensive experience as a NASA contractor. The company applied telemetry technology developed for the Saturn launch vehicle and the Apollo spacecraft; instrumentation technology developed for heart, blood pressure and sleep monitoring of astronauts aboard NASA's Skylab long duration space station; and communications technology developed for the Space Shuttle.

Source record↗
NASA NTRS1999

Satellite antenna management system and method

The antenna management system and method allow a satellite to communicate with a ground station either directly or by an intermediary of a second satellite, thus permitting communication even when the satellite is not within range of the ground station. The system and method employ five major software components, which are the control and initialization module, the command and telemetry handler module, the contact schedule processor module, the contact state machining module, and the telemetry state machine module. The control and initialization module initializes the system and operates the main control cycle, in which the other modules are called. The command and telemetry handler module handles communication to and from the ground station. The contact scheduler processor module handles the contact entry schedules to allow scheduling of contacts with the second satellite. The contact and telemetry state machine modules handle the various states of the satellite in beginning, maintaining and ending contact with the second satellite and in beginning, maintaining and ending communication with the satellite.

Leath, Timothy T↗
NASA NTRS2010

Spatio-Temporal Equalizer for a Receiving-Antenna Feed Array

A spatio-temporal equalizer has been conceived as an improved means of suppressing multipath effects in the reception of aeronautical telemetry signals, and may be adaptable to radar and aeronautical communication applications as well. This equalizer would be an integral part of a system that would also include a seven-element planar array of receiving feed horns centered at the focal point of a paraboloidal antenna that would be nominally aimed at or near the aircraft that would be the source of the signal that one seeks to receive (see Figure 1). This spatio-temporal equalizer would consist mostly of a bank of seven adaptive finite-impulse-response (FIR) filters one for each element in the array - and the outputs of the filters would be summed (see Figure 2). The combination of the spatial diversity of the feedhorn array and the temporal diversity of the filter bank would afford better multipath-suppression performance than is achievable by means of temporal equalization alone. The seven-element feed array would supplant the single feed horn used in a conventional paraboloidal ground telemetry-receiving antenna. The radio-frequency telemetry signals re ceiv ed by the seven elements of the array would be digitized, converted to complex baseband form, and sent to the FIR filter bank, which would adapt itself in real time to enable reception of telemetry at a low bit error rate, even in the presence of multipath of the type found at many flight test ranges.

Mukai, Ryan↗
NASA NTRS2010

Reinventing User Applications for Mission Control

In 2006, NASA Ames Research Center's (ARC) Intelligent Systems Division, and NASA Johnson Space Centers (JSC) Mission Operations Directorate (MOD) began a collaboration to move user applications for JSC's mission control center to a new software architecture, intended to replace the existing user applications being used for the Space Shuttle and the International Space Station. It must also carry NASA/JSC mission operations forward to the future, meeting the needs for NASA's exploration programs beyond low Earth orbit. Key requirements for the new architecture, called Mission Control Technologies (MCT) are that end users must be able to compose and build their own software displays without the need for programming, or direct support and approval from a platform services organization. Developers must be able to build MCT components using industry standard languages and tools. Each component of MCT must be interoperable with other components, regardless of what organization develops them. For platform service providers and MOD management, MCT must be cost effective, maintainable and evolvable. MCT software is built from components that are presented to users as composable user objects. A user object is an entity that represents a domain object such as a telemetry point, a command, a timeline, an activity, or a step in a procedure. User objects may be composed and reused, for example a telemetry point may be used in a traditional monitoring display, and that same telemetry user object may be composed into a procedure step. In either display, that same telemetry point may be shown in different views, such as a plot, an alpha numeric, or a meta-data view and those views may be changed live and in place. MCT presents users with a single unified user environment that contains all the objects required to perform applicable flight controller tasks, thus users do not have to use multiple applications, the traditional boundaries that exist between multiple heterogeneous applications disappear, leaving open the possibility of new operations concepts that are not constrained by the traditional applications paradigm.

Trimble, Jay Phillip↗
NASA NTRS2004

High-Rate Digital Receiver Board

A high-rate digital receiver (HRDR) implemented as a peripheral component interface (PCI) board has been developed as a prototype of compact, general-purpose, inexpensive, potentially mass-producible data-acquisition interfaces between telemetry systems and personal computers. The installation of this board in a personal computer together with an analog preprocessor enables the computer to function as a versatile, highrate telemetry-data-acquisition and demodulator system. The prototype HRDR PCI board can handle data at rates as high as 600 megabits per second, in a variety of telemetry formats, transmitted by diverse phase-modulation schemes that include binary phase-shift keying and various forms of quadrature phaseshift keying. Costing less than $25,000 (as of year 2003), the prototype HRDR PCI board supplants multiple racks of older equipment that, when new, cost over $500,000. Just as the development of standard network-interface chips has contributed to the proliferation of networked computers, it is anticipated that the development of standard chips based on the HRDR could contribute to reductions in size and cost and increases in performance of telemetry systems.

Ghuman, Parminder↗
NASA NTRS2011

SpaceCube Demonstration Platform

A document discusses how the HST SM4 SpaceCube flight spare was modified to create an experiment called the Space- Cube Demonstration Platform (SC DP) for use on the MISSE7 Space Station payload (in collaboration with NRL). It is designed to serve as an on-orbit platform for demonstrating advanced fault tolerance technologies. A simple C&DH (command and data handling) system was developed for the Virtex4 FPGAs (field programmable gate arrays). Both Virtex4s on each SpaceCube run the same program, and both receive incoming telemetry. The rad-hard service FPGA performs simple error checking to verify that the incoming telemetry is valid. The SpaceCube framework was modified to allow for new program files to be sent from the ground, to be stored on the SpaceCube, and to be executed through ground commands. Each SpaceCube Virtex4 FPGA has resources set aside for experiments that are functionally isolated from the C&DH system. The experiments communicate to the C&DH system through a set of dual port memories, and this area is where the fault-tolerance experiments are executed. With the use of Xilinx commercial Virtex4 FX60 FPGAs, the fault tolerant framework allows the system to recover from radiation upsets that occur in the rad-soft parts (Virtex4 FPGA logic, embedded PPCs in Virtex4 FPGAs, SDRAM and Flash), the C&DH system that runs simultaneously on both Virtex4 FPGAs that uses a robust telemetry packet structure, checksums, and the rad-hard service FPGA to validate incoming telemetry. The ability to be reconfigured from the ground while in orbit is a novel benefit, as well as is the onboard compression capabilities that allow compressed files from the ground to be uploaded to the SpaceCube.

Espinosa, Daniel↗
NASA NTRS2011

Digital Interface Board to Control Phase and Amplitude of Four Channels

An increasing number of parts are designed with digital control interfaces, including phase shifters and variable attenuators. When designing an antenna array in which each antenna has independent amplitude and phase control, the number of digital control lines that must be set simultaneously can grow very large. Use of a parallel interface would require separate line drivers, more parts, and thus additional failure points. A convenient form of control where single-phase shifters or attenuators could be set or the whole set could be programmed with an update rate of 100 Hz is needed to solve this problem. A digital interface board with a field-programmable gate array (FPGA) can simultaneously control an essentially arbitrary number of digital control lines with a serial command interface requiring only three wires. A small set of short, high-level commands provides a simple programming interface for an external controller. Parity bits are used to validate the control commands. Output timing is controlled within the FPGA to allow for rapid update rates of the phase shifters and attenuators. This technology has been used to set and monitor eight 5-bit control signals via a serial UART (universal asynchronous receiver/transmitter) interface. The digital interface board controls the phase and amplitude of the signals for each element in the array. A host computer running Agilent VEE sends commands via serial UART connection to a Xilinx VirtexII FPGA. The commands are decoded, and either outputs are set or telemetry data is sent back to the host computer describing the status and the current phase and amplitude settings. This technology is an integral part of a closed-loop system in which the angle of arrival of an X-band uplink signal is detected and the appropriate phase shifts are applied to the Ka-band downlink signal to electronically steer the array back in the direction of the uplink signal. It will also be used in the non-beam-steering case to compensate for phase shift variations through power amplifiers. The digital interface board can be used to set four 5-bit phase shifters and four 5-bit attenuators and monitor their current settings. Additionally, it is useful outside of the closed-loop system for beamsteering alone. When the VEE program is started, it prompts the user to initialize variables (to zero) or skip initialization. After that, the program enters into a continuous loop waiting for the telemetry period to elapse or a button to be pushed. A telemetry request is sent when the telemetry period is elapsed (every five seconds). Pushing one of the set or reset buttons will send the appropriate command. When a command is sent, the interface status is returned, and the user will be notified by a pop-up window if any error has occurred. The program runs until the End Program button is depressed.

Smith, Amy E.↗
NASA NTRS2005

Monitoring Agents for Assisting NASA Engineers with Shuttle Ground Processing

The Spaceport Processing Systems Branch at NASA Kennedy Space Center has designed, developed, and deployed a rule-based agent to monitor the Space Shuttle's ground processing telemetry stream. The NASA Engineering Shuttle Telemetry Agent increases situational awareness for system and hardware engineers during ground processing of the Shuttle's subsystems. The agent provides autonomous monitoring of the telemetry stream and automatically alerts system engineers when user defined conditions are satisfied. Efficiency and safety are improved through increased automation. Sandia National Labs' Java Expert System Shell is employed as the agent's rule engine. The shell's predicate logic lends itself well to capturing the heuristics and specifying the engineering rules within this domain. The declarative paradigm of the rule-based agent yields a highly modular and scalable design spanning multiple subsystems of the Shuttle. Several hundred monitoring rules have been written thus far with corresponding notifications sent to Shuttle engineers. This chapter discusses the rule-based telemetry agent used for Space Shuttle ground processing. We present the problem domain along with design and development considerations such as information modeling, knowledge capture, and the deployment of the product. We also present ongoing work with other condition monitoring agents.

Semmel, Glenn S.↗
NASA NTRS2013

XTCE GOVSAT Tool Suite 1.0

The XTCE GOVSAT software suite contains three tools: validation, search, and reporting. The Extensible Markup Language (XML) Telemetric and Command Exchange (XTCE) GOVSAT Tool Suite is written in Java for manipulating XTCE XML files. XTCE is a Consultative Committee for Space Data Systems (CCSDS) and Object Management Group (OMG) specification for describing the format and information in telemetry and command packet streams. These descriptions are files that are used to configure real-time telemetry and command systems for mission operations. XTCE s purpose is to exchange database information between different systems. XTCE GOVSAT consists of rules for narrowing the use of XTCE for missions. The Validation Tool is used to syntax check GOVSAT XML files. The Search Tool is used to search (i.e. command and telemetry mnemonics) the GOVSAT XML files and view the results. Finally, the Reporting Tool is used to create command and telemetry reports. These reports can be displayed or printed for use by the operations team.

Rice, J. Kevin↗
NASA NTRS2012

CASSIUS: The Cassini Uplink Scheduler

The Cassini Uplink Scheduler (CASSIUS) is cross-platform software used to generate a radiation sequence plan for commands being sent to the Cassini spacecraft. Because signals must travel through varying amounts of Earth's atmosphere, several different modes of constant telemetry rates have been devised. These modes guarantee that the spacecraft and the Deep Space Network agree with respect to the data transmission rate. However, the memory readout of a command will be lost if it occurs on a telemetry mode boundary. Given a list of spacecraft message files as well as the available telemetry modes, CASSIUS can find an uplink sequence that ensures safe transmission of each file. In addition, it can predict when the two on-board solid state recorders will swap. CASSIUS prevents data corruption by making sure that commands are not planned for memory readout during telemetry rate changes or a solid state recorder swap.

Cassini mission↗
NASA NTRS2011

Characterizing Observed Limit Cycles in the Cassini Main Engine Guidance Control System

The Cassini spacecraft dynamics-related telemetry during long Main Engine (ME) burns has indicated the presence of stable limit cycles between 0.03-0.04 Hz frequencies. These stable limit cycles cause the spacecraft to possess non-zero oscillating rates for extended periods of time. This indicates that the linear ME guidance control system does not model the complete dynamics of the spacecraft. In this study, we propose that the observed limit cycles in the spacecraft dynamics telemetry appear from a stable interaction between the unmodeled nonlinear elements in the ME guidance control system. Many nonlinearities in the control system emerge from translating the linear engine gimbal actuator (EGA) motion into a spacecraft rotation. One such nonlinearity comes from the gear backlash in the EGA system, which is the focus of this paper. The limit cycle characteristics and behavior can be predicted by modeling this gear backlash nonlinear element via a describing function and studying the interaction of this describing function with the overall dynamics of the spacecraft. The linear ME guidance controller and gear backlash nonlinearity are modeled analytically. The frequency, magnitude, and nature of the limit cycle are obtained from the frequency response of the ME guidance controller and nonlinear element. In addition, the ME guidance controller along with the nonlinearity is simulated. The simulation response contains a limit cycle with similar characterstics as predicted analytically: 0.03-0.04 Hz frequency and stable, sustained oscillations. The analytical and simulated limit cycle responses are compared to the flight telemetry for long burns such as the Saturn Orbit Insertion and Main Engine Orbit Trim Maneuvers. The analytical and simulated limit cycle characteristics compare well with the actual observed limit cycles in the flight telemetry. Both have frequencies between 0.03-0.04 Hz and stable oscillations. This work shows that the stable limit cycles occur due to the interaction between the unmodeled nonlinear elements and linear ME guidance controller.

stable limit cycle↗
NASA NTRS2008

Moving Away from Ones and Zeros, Designing a Ground Data System Based on Higher Levels of Abstraction

Previous JPL ground systems have been designed with the Ground Data System (GDS) engineer in mind. The focus on these systems has been on packaging and delivery of low level information (frames, packets, telemetry values) to the end user. It was not that long ago when project teams would be huddled over a workstation, examining crude displays of telemetry bits organized in various ways, trying to determine the status of a spacecraft. Understanding the data often required additional levels of GDS expertise, or worse, transformation of the raw data into alternative formats followed by ingestion into other tools so that the data became meaningful. The primary focus was often to answer these types of questions: "Why did this particular frame fail Reed-Solomon decode? Why did this packet get marked as invalid? Why am I missing a block of telemetry from my query?" -- which are completely valid questions to ask from a GDS Engineer's point of view, and large families of tools have been designed to help answer these questions. But these are not the questions that most users care about - which are more like: "Why is the battery state of charge trending down? Show me a summary image report for the last traverse to the target. Show me a data accountability summary for the last DSN pass." Answers to these questions, which are what users are looking for, requires a higher level of abstraction and supporting tools than mining through ones and zeros. JPL has created a next generation capability called the Mission Data Processing and Control System (MPCS) which is designed to support this higher level of abstraction by providing customizable views of the ground system combining collections of lower level information into more meaningful ways. Instead of examining frames, packets, and individual telemetry data points -- MPCS is capable of providing comprehensive summary reports, product status, overall flight/ground event status, as well as payload health summaries. Based on these higher level views, end users can make tactical or strategic decisions, or drop into detailed analysis as needed. System designers need to continue building systems that support low level GDS troubleshooting - but the basic design of a GDS should be geared towards what end users actually need to see. This paper will describe the capabilities of MPCS that directly support these higher levels of abstraction, and which are being used today in missions such as the Mars Science Laboratory and other NASA missions.

MPCS↗
NASA NTRS2017

Virtualized Multi-Mission Operations Center (vMMOC) and its Cloud Services

His presentation will cover, the current and future, technical and organizational opportunities and challenges with virtualizing a multi-mission operations center. The full deployment of Goddard Space Flight Centers (GSFC) Virtualized Multi-Mission Operations Center (vMMOC) is nearly complete. The Space Science Mission Operations (SSMO) organizations spacecraft ACE, Fermi, LRO, MMS(4), OSIRIS-REx, SDO, SOHO, Swift, and Wind are in the process of being fully migrated to the vMMOC. The benefits of the vMMOC will be the normalization and the standardization of IT services, mission operations, maintenance, and development as well as ancillary services and policies such as collaboration tools, change management systems, and IT Security. The vMMOC will also provide operational efficiencies regarding hardware, IT domain expertise, training, maintenance and support.The presentation will also cover SSMO's secure Situational Awareness Dashboard in an integrated, fleet centric, cloud based web services fashion. Additionally the SSMO Telemetry as a Service (TaaS) will be covered, which allows authorized users and processes to access telemetry for the entire SSMO fleet, and for the entirety of each spacecrafts history. Both services leverage cloud services in a secure FISMA High and FedRamp environment, and also leverage distributed object stores in order to house and provide the telemetry. The services are also in the process of leveraging the cloud computing services elasticity and horizontal scalability. In the design phase is the Navigation as a Service (NaaS) which will provide a standardized, efficient, and normalized service for the fleet's space flight dynamics operations. Additional future services that may be considered are Ground Segment as a Service (GSaaS), Telemetry and Command as a Service (TCaaS), Flight Software Simulation as a Service, etc.

Ido, Haisam Kassim↗
DOE OSTI2011

Evaluation of Behavioral Guidance Structure on Juvenile Salmonid Passage and Survival at Bonneville Dam in 2009

Pacific Northwest National Laboratory (PNNL) conducted an acoustic-telemetry study at Bonneville Dam in 2009 to evaluate the effects of a behavioral guidance structure (BGS) in the Bonneville Dam second powerhouse forebay on fish passage and survival through the second powerhouse (B2), the dam as a whole, and through the first powerhouse and spillway combined. The BGS was deployed to increase the survival of fish passing through B2 by increasing the percentage of outmigrating smolts entering the B2 Corner Collector (B2CC)—a surface flow outlet known to be a relatively benign route for downstream passage at this dam. The study relied on releases of live Juvenile Salmon Acoustic Telemetry System tagged smolts in the Columbia River and used acoustic telemetry to evaluate the approach, passage, and survival of passing juvenile salmon. Study results indicated that having turbine 11 in service is important for providing flow conditions that are comparable to those observed in pre-BGS years (2004 and 2005) and in 2008. This study supports the U.S. Army Corps of Engineers continual effort to improve conditions for juvenile anadromous fish passing through Columbia River dams.

13 HYDRO ENERGY↗
DOE OSTI2011

Survival and Passage of Juvenile Chinook Salmon and Steelhead Passing through Bonneville Dam, 2010

Pacific Northwest National Laboratory (PNNL) and subcontractors conducted an acoustic-telemetry study of juvenile salmonid fish passage and survival at Bonneville Dam in 2010. The study was conducted to assess the readiness of the monitoring system for official compliance studies under the 2008 Biological Opinion and Fish Accords and to assess performance measures including route-specific fish passage proportions, travel times, and survival based upon a single-release model. This also was the last year of evaluation of effects of a behavioral guidance device installed in the Powerhouse 2 forebay. The study relied on releases of live Juvenile Salmon Acoustic Telemetry System tagged smolts in the Columbia River and used acoustic telemetry to evaluate the approach, passage, and survival of passing juvenile salmon. This study supports the U.S. Army Corps of Engineers continual effort to improve conditions for juvenile anadromous fish passing through Columbia River dams.

13 HYDRO ENERGY↗
DOE OSTI2013

Survival and Passage of Juvenile Chinook Salmon and Steelhead Passing through Bonneville Dam, 2011

Pacific Northwest National Laboratory (PNNL) and subcontractors conducted an acoustic-telemetry study of juvenile salmonid fish passage and survival at Bonneville Dam in 2011. The study was conducted to assess the readiness of the monitoring system for official compliance studies under the 2008 Biological Opinion and Fish Accords and to assess performance measures including route-specific fish passage proportions, travel times, and survival based upon a virtual/paired-release model. The study relied on releases of live Juvenile Salmon Acoustic Telemetry System tagged smolts in the Columbia River and used acoustic telemetry to evaluate the approach, passage, and survival of passing juvenile salmon using a virtual release, paired reference release survival model. This study supports the U.S. Army Corps of Engineers’ continual effort to improve conditions for juvenile anadromous fish passing through Columbia River dams.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS2005

Hyper-X (X-43A) Flight Test Range Operations

The Hyper-X program flew X-43A research vehicles to hypersonic speeds over the Pacific Ocean in March and November 2004 from the Western Aeronautical Test Range, NASA Dryden Flight Research Center, Edwards, California. The program required multiple telemetry ground stations to provide continuous coverage of the captive carry, launch, boost, experiment, and descent phases of these missions. An overview is provided of vehicle telemetry and distributed assets that supported telemetry acquisition, best-source selection, radar tracking, video tracking, flight termination systems, and voice communications. Real-time data display and processing are discussed, and postflight analysis and comparison of data acquired are presented.

Hyper-X↗
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↗