Search NASA⌕ Search

SEARCH · Search NASA

Results for “packet 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 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS2016

Next Generation Flight Displays Using HTML5

The Human Integrated Vehicles and Environments (HIVE) lab at Johnson Space Center (JSC) is focused on bringing together inter-disciplinary talent to design and integrate innovative human interface technologies for next generation manned spacecraft. As part of this objective, my summer internship project centered on an ongoing investigation in to building flight displays using the HTML5 standard. Specifically, the goals of my project were to build and demo "flight-like" crew and wearable displays as well as create a webserver for live systems being developed by the Advanced Exploration Systems (AES) program. In parallel to my project, a LabVIEW application, called a display server, was created by the HIVE that uses an XTCE (XML (Extensible Markup Language) Telemetry and Command Exchange) parser and CCSDS (Consultative Committee for Space Data System) space packet decoder to translate telemetry items sent by the CFS (Core Flight Software) over User Datagram Protocol (UDP). It was the webserver's job to receive these UDP messages and send them to the displays. To accomplish this functionality, I utilized Node.js and the accompanying Express framework. On the display side, I was responsible for creating the power system (AMPS) displays. I did this by using HTML5, CSS and JavaScript to create web pages that could update and change dynamically based on the data they received from the webserver. At this point, I have not started on the commanding, being able to send back to the CFS, portion of the displays but hope to have this functionality working by the completion of my internship. I also created a way to test the webserver's functionality without the display server by making a JavaScript application that read in a comma-separate values (CSV) file and converted it to XML which was then sent over UDP. One of the major requirements of my project was to build everything using as little preexisting code as possible, which I accomplished by only using a handful of JavaScript libraries. As a side project, I created a model of the HIVE lab and Building 29 using SketchUp. I obtained the floorplans of the building from the JSC Geographic Information Systems (GIS), which were computer-aided design (CAD) files, and imported them into SketchUp. I then took those floorplans and created a 3D model of the building from them. Working in conjunction with the Hybrid Reality lab in Building 32, the SketchUp model was imported into Unreal Engine for use with the HTC Vive. Using the Vive, I was able to interact with the model I created in virtual reality (VR). The purpose of this side project was to be able to visualize potential lab layouts and mockup designs as they are in development in order to finalize design decisions. Pending approval, the model that I created will be used in the Build-As-You-Test: Can Hybrid Reality Improve the SE/HSI Design Process project in the fall. Getting the opportunity to work at NASA has been one of the most memorable experiences of my life. Over the course of my internship, I improved my programming and web development abilities substantially. I will take all the skills and experiences I have had while at NASA back to school with me in the fall and hope to pursue a career in the aerospace industry after graduating in the spring.

Greenwood, Brian↗
NASA NTRS2018

Methods and Apparatus for Aggregation of Multiple Pulse Code Modulation Channels into a Signal Time Division Multiplexing Stream

Methods and apparatus are provided for telemetry processing using a telemetry processor. The telemetry processor can include a plurality of communications interfaces, a computer processor, and data storage. The telemetry processor can buffer sensor data by: receiving a frame of sensor data using a first communications interface and clock data using a second communications interface, receiving an end of frame signal using a third communications interface, and storing the received frame of sensor data in the data storage. After buffering the sensor data, the telemetry processor can generate an encapsulated data packet including a single encapsulated data packet header, the buffered sensor data, and identifiers identifying telemetry devices that provided the sensor data. A format of the encapsulated data packet can comply with a Consultative Committee for Space Data Systems (CCSDS) standard. The telemetry processor can send the encapsulated data packet using a fourth and a fifth communications interfaces.

Chang, Chen J.↗
DOE OSTI2025

Real-Time Testbed for Studying Cyberattacks and Defense in DER-integrated Smart Inverter Systems

In this paper, we propose a Hardware-in-the-Loop (HIL) simulation testbed suitable for the implementation and testing of realistic cyberattacks on grid-tied smart inverter systems integrated with Distributed Energy Resources (DER) that use the Distributed Network Protocol-3 (DNP3) protocol for communications between grid components. Specifically, our testbed combines a Real-Time Digital Simulator (RTDS) NovaCor device, outfitted with GNETx2 network interface cards, a gridtied DER topology implemented via the RTDS software package RSCAD, and a custom virtual network that emulates a man in the middle attacker. The Man-in-the-Middle (MITM) attacker captures DNP3 traffic and falsifies telemetry data in DNP3 packets to trigger unwarranted commands from a DNP3 controller that exploit smart inverter grid support functions. We choose DNP3 and implement grid support functions according to the IEEE Std. 1547-2018 mandated for the interconnection and interoperability of DER power systems with associated power components. Furthermore, we develop a protocol payload agnostic attack detection framework that leverages the round-trip time (RTT) anomalies between DNP3 requests and responses and can detect the presence of attacks without having to analyze the payload’s contents, while balancing trade-offs between false alarm counts, missed detections, and time to detection. To facilitate further research, we publicly release benign and attack network traffic exchanged between various sensors, controllers, and actuators in our grid-tied inverter testbed.

24 POWER TRANSMISSION AND DISTRIBUTION↗
NASA NTRS2004

Space-Based Telemetry and Range Safety (STARS) Study

This presentation will describe the design, development, and testing of a system to collect telemetry, format it into UDP/IP packets, and deliver it to a ground test range using standard IP technologies over a TDRSS link. This presentation will discuss the goal of the STARS IP Formatter along with the overall design. It will also present performance results of the current version of the IP formatter. Finally, it will discuss key issues for supporting constant rate telemetry data delivery when using standard components such as PCI/104 processors, the Linux operating system, Internet Protocols, and synchronous serial interfaces.

Hogie, Keith↗
NASA NTRS2010

XTCE. XML Telemetry and Command Exchange Tutorial

An XML Telemetry Command Exchange (XTCE) tutoral oriented towards packets or minor frames is shown. The contents include: 1) The Basics; 2) Describing Telemetry; 3) Describing the Telemetry Format; 4) Commanding; 5) Forgotten Elements; 6) Implementing XTCE; and 7) GovSat.

Rice, Kevin↗
NASA NTRS1997

MOLA II Laser Transmitter Calibration and Performance

The goal of the document is to explain the algorithm for determining the laser output energy from the telemetry data within the return packets from MOLA II. A simple algorithm is developed to convert the raw start detector data into laser energy, measured in millijoules. This conversion is dependent on three variables, start detector counts, array heat sink temperature and start detector temperature. All these values are contained within the return packets. The conversion is applied to the GSFC Thermal Vacuum data as well as the in-space data to date and shows good correlation.

Afzal, Robert S.↗
DOE OSTI2025

eCounter: Inline Per-IP Network Monitoring at Millisecond Resolution via eBPF

Scientific data acquisition (SciDAQ) systems are shifting from archive-based workflows to streaming paradigms, where real-time, fine-grained network monitoring becomes essential. While P4-enabled devices offer per-packet in-band observability, they require specialized switches and routers. Host-side tools like Prometheus exporters lack sufficient temporal granularity. To bridge this gap, we present eCounter, a lightweight, hardware-agnostic, inline telemetry agent built on extended Berkeley Packet Filter (eBPF). eCounter captures per-interface ingress and egress traffic, categorized by IP address and protocol, at millisecond to sub-millisecond resolution. In a 100 Gbps environment, it continuously exports up to 3,257 time-series bins per second with only 4% CPU utilization at a 35¿KiB/s data rate. We evaluate eCounter across diverse NIC MTU settings, hook types, CPU architectures and operating systems, and observed negligible impact on concurrent high-throughput streaming applications. Complexity analysis confirms that it can be readily scaled to distributed SciDAQ deployments.

Mei, Xinxin [Computational Sciences and Technology↗
NASA NTRS1988

VLSI high speed packet processor

The Goddard Space Flight Center Mission Operations and Data Systems Directorate has developed a packet processor card utilizing semicustom very large scale integration (VLSI) devices, microprocessors, and programmable gate arrays to support the implementation of multichannel telemetry data capture systems. This card will receive synchronized error corrected telemetry transfer frames and output annotated application packets derived from this data. An adaptable format capability is provided by the programmability of three microprocessors while the throughput capability of the packet processor is achieved by a data pipeline consisting of two separate RAM systems controlled by specially designed semicustom VLSI logic.

Grebowsky, Gerald J.↗
NASA NTRS2019

Software Development and Testing Support for the Avionics Systems Telemetry Tool Suite

The Customer Avionics Interface Development and Analysis (CAIDA) team provides modeling and simulation software for the verification of the Launch Control System (LCS). In late 2015, CAIDA began development of the Data Exchange Message (DEM) Generator (DEMGen) and development of the DEM Modifier (DEMMod) in early 2017. DEMGen is able to mimic the telemetry streams normally sent by different simulators allowing increased user control and more telemetry instances. DEMMod takes in a telemetry stream and allows the modification of entire packets or simple measurement values. Together, these tools provide the capabilities to simulate and test complex launch scenarios to ensure LCS is fully prepared for any anomalous behavior during an actual launch. In early 2018, CAIDA began a new project called the CAIDA Advanced Telemetry Tool (CATT), which combined the code and documentation of DEMGen and DEMMod. CATT now allows the integration of new tools into a singular program providing compact and easy access. In the fall of 2018, the author worked with another intern, Antonio Negron, to develop several new CATT features along with proper documentation and unit testing. In the following spring, the author continued that work by integrating the features into CATT, solidifying the documentation, and expanding the testing to cover more cases. The outcome of both semesters includes an inspection engine for automated packet analysis, a packet-masking feature, and a multi-measurement sequencing feature.

Thomas, Taylor Walter↗
NASA NTRS1978

A concept for a transparent data acquisition and distribution system for spaceflight applications

The paper describes the Modular Data System concept of the NASA End-to-End Data System program. Data from a single instrument along with the necessary ancillary data will be assembled into self-contained packets and subsequently transmitted over various communications links (space telemetry channel, ground communications circuits, etc.) to the experimenter's facility in real time; reliable error control coding will be included in each link transmission to protect the integrity of the data packets. A major objective is to make the entire data acquisition and distribution process transparent to the experimenter in the sense that the output terminal of the distribution system will be physically, logically and electrically identical to that of the experiment output channel.

Greene, E. P.↗
NASA NTRS2015

Telescience Resource Kit (TReK)

Telescience Resource Kit (TReK) is one of the Huntsville Operations Support Center (HOSC) remote operations solutions. It can be used to monitor and control International Space Station (ISS) payloads from anywhere in the world. It is comprised of a suite of software applications and libraries that provide generic data system capabilities and access to HOSC services. The TReK Software has been operational since 2000. A new cross-platform version of TReK is under development. The new software is being released in phases during the 2014-2016 timeframe. The TReK Release 3.x series of software is the original TReK software that has been operational since 2000. This software runs on Windows. It contains capabilities to support traditional telemetry and commanding using CCSDS (Consultative Committee for Space Data Systems) packets. The TReK Release 4.x series of software is the new cross platform software. It runs on Windows and Linux. The new TReK software will support communication using standard IP protocols and traditional telemetry and commanding. All the software listed above is compatible and can be installed and run together on Windows. The new TReK software contains a suite of software that can be used by payload developers on the ground and onboard (TReK Toolkit). TReK Toolkit is a suite of lightweight libraries and utility applications for use onboard and on the ground. TReK Desktop is the full suite of TReK software -most useful on the ground. When TReK Desktop is released, the TReK installation program will provide the option to choose just the TReK Toolkit portion of the software or the full TReK Desktop suite. The ISS program is providing the TReK Toolkit software as a generic flight software capability offered as a standard service to payloads. TReK Software Verification was conducted during the April/May 2015 timeframe. Payload teams using the TReK software onboard can reference the TReK software verification. TReK will be demonstrated on-orbit running on an ISS provided T61p laptop. Target Timeframe: September 2015 -2016. The on-orbit demonstration will collect benchmark metrics, and will be used in the future to provide live demonstrations during ISS Payload Conferences. Benchmark metrics and demonstrations will address the protocols described in SSP 52050-0047 Ku Forward section 3.3.7. (Associated term: CCSDS File Delivery Protocol (CFDP)).

Lippincott, Jeff↗
NASA NTRS2018

Use of Nack Oriented Reliable Multicast (NORM) Protocol for Transport of Spacecraft Telemetry in Ground Networks

Frequently it is necessary to distribute spacecraft telemetry to multiple destinations on Internet Protocol (IP) networks. There are various methods of delivering this data, but when the data is high rate and there are many destinations IP multicast provides the best solution from a network perspective. However, IP multicast only supports the User Datagram Protocol (UDP) which is connectionless and unreliable. This nature of UDP and by extension the low priority treatment of UDP packets by some network hardware creates a difficult environment for distribution of high rate telemetry to a number of recipients over IP networks. NACK (Negative ACKnowledgment) Oriented Reliable Multicast (NORM) is defined by IETF (Internet Engineering Task Force) RFC (Request for Comments) 5740 in 2009 by B. Adamson et al. NORM provides a mechanism of retransmission and or forward error correction for UDP packets, potentially overcoming the limits of UDP for the transmission of spacecraft telemetry. Marshall Space Flight Center’s (MSFC) Huntsville Operations Support Center (HOSC) manages the delivery of the International Space Station (ISS) payload science and health data. The ISS IP Ground Routed (IIGoR) network provides the delivery of the data from the ground stations to the control centers. HOSC personnel have been experimenting with the use of NORM on the link between the ground stations and the front end processor equipment in Huntsville, AL.

Baldwin, Patrick A.↗
NASA NTRS1994

Test Telemetry And Command System (TTACS)

The Jet Propulsion Laboratory has developed a multimission Test Telemetry and Command System (TTACS) which provides a multimission telemetry and command data system in a spacecraft test environment. TTACS reuses, in the spacecraft test environment, components of the same data system used for flight operations; no new software is developed for the spacecraft test environment. Additionally, the TTACS is transportable to any spacecraft test site, including the launch site. The TTACS is currently operational in the Galileo spacecraft testbed; it is also being provided to support the Cassini and Mars Surveyor Program projects. Minimal personnel data system training is required in the transition from pre-launch spacecraft test to post-launch flight operations since test personnel are already familiar with the data system's operation. Additionally, data system components, e.g. data display, can be reused to support spacecraft software development; and the same data system components will again be reused during the spacecraft integration and system test phases. TTACS usage also results in early availability of spacecraft data to data system development and, as a result, early data system development feedback to spacecraft system developers. The TTACS consists of a multimission spacecraft support equipment interface and components of the multimission telemetry and command software adapted for a specific project. The TTACS interfaces to the spacecraft, e.g., Command Data System (CDS), support equipment. The TTACS telemetry interface to the CDS support equipment performs serial (RS-422)-to-ethernet conversion at rates between 1 bps and 1 mbps, telemetry data blocking and header generation, guaranteed data transmission to the telemetry data system, and graphical downlink routing summary and control. The TTACS command interface to the CDS support equipment is nominally a command file transferred in non-real-time via ethernet. The CDS support equipment is responsible for metering the commands to the CDS; additionally for Galileo, TTACS includes a real-time-interface to the CDS support equipment. The TTACS provides the basic functionality of the multimission telemetry and command data system used during flight operations. TTACS telemetry capabilities include frame synchronization, Reed-Solomon decoding, packet extraction and channelization, and data storage/query. Multimission data display capabilities are also available. TTACS command capabilities include command generation verification, and storage.

Fogel, Alvin J.↗
NASA NTRS2012

Use of CCSDS Packets Over SpaceWire to Control Hardware

For the Lunar Reconnaissance Orbiter, the Command and Data Handling subsystem consisted of several electronic hardware assemblies that were connected with SpaceWire serial links. Electronic hardware would be commanded/controlled and telemetry data was obtained using the SpaceWire links. Prior art focused on parallel data buses and other types of serial buses, which were not compatible with the SpaceWire and the core flight executive (CFE) software bus. This innovation applies to anything that utilizes both SpaceWire networks and the CFE software. The CCSDS (Consultative Committee for Space Data Systems) packet contains predetermined values in its payload fields that electronic hardware attached at the terminus of the SpaceWire node would decode, interpret, and execute. The hardware s interpretation of the packet data would enable the hardware to change its state/configuration (command) or generate status (telemetry). The primary purpose is to provide an interface that is compatible with the hardware and the CFE software bus. By specifying the format of the CCSDS packet, it is possible to specify how the resulting hardware is to be built (in terms of digital logic) that results in a hardware design that can be controlled by the CFE software bus in the final application

Haddad, Omar↗
NASA NTRS2012

High-Altitude MMIC Sounding Radiometer for the Global Hawk Unmanned Aerial Vehicle

Microwave imaging radiometers operating in the 50-183 GHz range for retrieving atmospheric temperature and water vapor profiles from airborne platforms have been limited in the spatial scales of atmospheric structures that are resolved not because of antenna aperture size, but because of high receiver noise masking the small variations that occur on small spatial scales. Atmospheric variability on short spatial and temporal scales (second/ km scale) is completely unresolved by existing microwave profilers. The solution was to integrate JPL-designed, high-frequency, low-noise-amplifier (LNA) technology into the High-Altitude MMIC Sounding Radiometer (HAMSR), which is an airborne microwave sounding radiometer, to lower the system noise by an order of magnitude to enable the instrument to resolve atmospheric variability on small spatial and temporal scales. HAMSR has eight sounding channels near the 60-GHz oxygen line complex, ten channels near the 118.75-GHz oxygen line, and seven channels near the 183.31-GHz water vapor line. The HAMSR receiver system consists of three heterodyne spectrometers covering the three bands. The antenna system consists of two back-to-back reflectors that rotate together at a programmable scan rate via a stepper motor. A single full rotation includes the swath below the aircraft followed by observations of ambient (roughly 0 C in flight) and heated (70 C) blackbody calibration targets located at the top of the rotation. A field-programmable gate array (FPGA) is used to read the digitized radiometer counts and receive the reflector position from the scan motor encoder, which are then sent to a microprocessor and packed into data files. The microprocessor additionally reads telemetry data from 40 onboard housekeeping channels (containing instrument temperatures), and receives packets from an onboard navigation unit, which provides GPS time and position as well as independent attitude information (e.g., heading, roll, pitch, and yaw). The raw data files are accessed through an Ethernet port. The HAMSR data rate is relatively low at 75 kbps, allowing for real-time access over the Global Hawk high-data-rate downlink. Once on the ground, the raw data are unpacked and processed through two levels of processing. The Level 1 product contains geo-located, time-stamped, calibrated brightness temperatures for the Earth scan. These data are then input to a lD variational retrieval algorithm to produce temperature, water vapor, and cloud liquid water profiles, as well as several derived products such as potential temperature and relative humidity.

Brown, Shannon T.↗
NASA NTRS1988

Functional component approach to telemetry data capture systems

A functional component approach to telemetry data capture systems is under development at the Mission Operations and Data Systems Directorate at the Goddard Space Flight Center which could support telemetry system needs in the next decade. The objective is to develop a library of functional modules which perform common telemetry functions. Some common telemetry data capture functions are NASA communications block processing, frame synchronization, Reed/Solomon decoding, packet processing, and virtual channel sorting/multiplexing.

Sabia, Steve↗
NASA NTRS1993

Making tomorrow's mistakes today: Evolutionary prototyping for risk reduction and shorter development time

In the early days of JPL's solar system exploration, each spacecraft mission required its own dedicated data system with all software applications written in the mainframe's native assembly language. Although these early telemetry processing systems were a triumph of engineering in their day, since that time the computer industry has advanced to the point where it is now advantageous to replace these systems with more modern technology. The Space Flight Operations Center (SFOC) Prototype group was established in 1985 as a workstation and software laboratory. The charter of the lab was to determine if it was possible to construct a multimission telemetry processing system using commercial, off-the-shelf computers that communicated via networks. The staff of the lab mirrored that of a typical skunk works operation -- a small, multi-disciplinary team with a great deal of autonomy that could get complex tasks done quickly. In an effort to determine which approaches would be useful, the prototype group experimented with all types of operating systems, inter-process communication mechanisms, network protocols, packet size parameters. Out of that pioneering work came the confidence that a multi-mission telemetry processing system could be built using high-level languages running in a heterogeneous, networked workstation environment. Experience revealed that the operating systems on all nodes should be similar (i.e., all VMS or all PC-DOS or all UNIX), and that a unique Data Transport Subsystem tool needed to be built to address the incompatibilities of network standards, byte ordering, and socket buffering. The advantages of building a telemetry processing system based on emerging industry standards were numerous: by employing these standards, we would no longer be locked into a single vendor. When new technology came to market which offered ten times the performance at one eighth the cost, it would be possible to attach the new machine to the network, re-compile the application code, and run. In addition, we would no longer be plagued with lack of manufacturer support when we encountered obscure bugs. And maybe, hopefully, the eternal elusive goal of software portability across different vendors' platforms would finally be available. Some highlights of our prototyping efforts are described.

Friedman, Gary↗
NASA NTRS1990

The Space Telescope SI C&DH system

The Hubble Space Telescope Scientific Instrument Control and Data Handling Subsystem (SI C&DH) is designed to interface with five scientific instruments of the Space Telescope to provide ground and autonomous control and collect health and status information using the Standard Telemetry and Command Components (STACC) multiplex data bus. It also formats high throughput science data into packets. The packetized data is interleaved and Reed-Solomon encoded for error correction and Pseudo Random encoded. An inner convolutional coding with the outer Reed-Solomon coding provides excellent error correction capability. The subsystem is designed with the capacity for orbital replacement in order to meet a mission life of fifteen years. The spacecraft computer and the SI C&DH computer coordinate the activities of the spacecraft and the scientific instruments to achieve the mission objectives.

Gadwal, Govind R.↗