Search NASA⌕ Search

SEARCH · Search NASA

Results for “Data Packets”

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 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2017

Method and Apparatus for Processing UDP Data Packets

A method and apparatus for processing a plurality of data packets. A data packet is received. A determination is made as to whether a portion of the data packet follows a selected digital recorder standard protocol based on a header of the data packet. Raw data in the data packet is converted into human-readable information in response to a determination that the portion of the data packet follows the selected digital recorder standard protocol.

Murphy, Brandon M.↗
NASA NTRS2006

General Solution for Theoretical Packet Data Loss Rate

Communications systems which transfer blocks ("frames") of data must use a marker ("frame synchronization pattern") for identifying where a block begins. A technique ("frame synchronization strategy") is used to locate the start of each frame and maintain synchronization as additional blocks are processed. A device which strips out the frame synchronization pattern [FSP] and provides an "end of frame" pulse is called a frame synchronizer. As clock and data errors are introduced into the system, the start-of-block marker becomes displaced and/or corrupted. The capability of the frame synchronizer to stay locked to the pattern under these conditions is a figure of merit for the frame synchronization strategy. It is important to select a strategy which will stay locked nearly all the time at bit error rates where the data is usable. ("Bit error rate" [BER] is the fraction of binary bits which are inverted by passage through a communication system.) The fraction of frames that are discarded because the frame synchronizer is not locked is called "Percent Data Loss" or "Packet Data Loss rate" [PDL]. A general approach for accurately predicting PDL given BER was developed in Theoretical Percent Data Loss Calculation and Measurement Accuracy, T. P. Kelly, LESC-30554, December 1992. Kelly gave a solution in terms of matrix equations, and only addressed "level" channel encoding. This paper goes on to give a closed-form polynomial solution for the most common class of frame synchronizer strategies, and will also address "mark" and "space" (differential) channel encoding, and burst error environments. The paper is divided into four sections and follows a logically ordered presentation, with results developed before they are evaluated. However, most readers will derive the greatest benefit from this paper by treating the results as reference material. The result developed for differential encoding can be extended to other applications (like block codes) where the probability is needed that a block contains only a certain number of errors.

Lansdowne, Chatwin↗
NASA NTRS1995

A packet data compressor

We are in the preliminary stages of creating an operational system for losslessly compressing packet data streams. The end goal is to reduce costs. Real world constraints include transmission in the presence of error, tradeoffs between the costs of compression and the costs of transmission and storage, and imperfect knowledge of the data streams to be transmitted. The overall method is to bring together packets of similar type, split the data into bit fields, and test a large number of compression algorithms. Preliminary results are very encouraging, typically offering compression factors substantially higher than those obtained with simpler generic byte stream compressors, such as Unix Compress and HA 0.98.

Grunes, Mitchell R.↗
NASA NTRS2014

Centering a DDR Strobe in the Middle of a Data Packet

The Orion CEV Northstar ASIC (application- specific integrated circuit) project required a DDR (double data rate) memory bus driver/receiver (DDR PHY block) to interface with external DDR memory. The DDR interface (JESD79C) is based on a source synchronous strobe (DQS\) that is sent along with each packet of data (DQ). New data is provided concurrently with each edge of strobe and is sent irregularly. In order to capture this data, the strobe needs to be delayed and used to latch the data into a register. A circuit solves the need for training a DDR PRY block by incorporating a PVT-compensated delay element in the strobe path. This circuit takes an external reference clock signal and uses the regular clock to calibrate a known delay through a data path. The compensated delay DQS signal is then used to capture the DQ data in a normal register. This register structure can be configured as a FIFO (first in first out), in order to transfer data from the DDR domain to the system clock domain. This design is different in that it does not rely upon the need for training the system response, nor does it use a PLL (phase locked loop) or a DLL (delay locked loop) to provide an offset of the strobe signal. The circuit is created using standard ASIC building blocks, plus the PVT (process, voltage, and temperature) compensated delay line. The design uses a globally available system clock as a reference, alleviating the need to operate synchronously with the remote memory. The reference clock conditions the PVT compensated delay line to provide a pre-determined amount of delay to any data signal that passes through this delay line. The delay line is programmed in degrees of offset, so that one could think of the clock period representing 360deg of delay. In an ideal environment, delaying the strobe 1/4 of a clock cycle (90deg) would place the strobe in the middle of the data packet. This delayed strobe can then be used to clock the data into a register, satisfying setup and hold requirements of the system.

Johnson, Michael↗
NASA NTRS1993

Design and implementation considerations of a MSAT packet data network

The Mobile Data System, which is intended to provide for packet switched data services is currently under development. The system is based on a star network topology consisting of a centralized Data Hub (DH) serving a large number of mobile terminals. Through the Data Hub, end-to-end connections can be established between terrestrial users on public or private data networks and mobile users. The MDS network will be capable of offering a variety of services some of which are based on the standard X.25 network interface protocol, and others optimized for short messages and broadcast messages. A description of these services and the trade-offs in the DH design are presented.

Karam, Fouad G.↗
DOE OSTI2026

Vera C. Rubin Observatory Prompt Products: alert packets data

Data products produced by prompt and daily processing of images obtained in the Legacy Survey of Space and Time. These include realtime alerts sent to community alert brokers, newly-discovered Solar System Objects reported to the Minor Planet Center, processed visit and difference images, and source catalogs. Prompt Products are not a static single data release but continually grow throughout the ten-year LSST survey. This dataset is a subset of the full data release consisting of a dataset named alert packets. This dataset contains measurements for 5-sigma sources detected in difference images that were issued to the community brokers.

79 ASTRONOMY AND ASTROPHYSICS↗
NASA NTRS1996

Electronic-To-Optical-To-Electronic Packet-Data Conversion

Space-time multiplexer (STM) cell-based communication system designed to take advantage of both high throughput attainable in optical transmission links and flexibility and functionality of electronic processing, storage, and switching. Long packets segmented and transmitted optically by wavelength-division multiplexing. Performs optoelectronic and protocol conversion between electronic "store-and-forward" protocols and optical "hot-potato" protocols.

Monacos, Steve↗
NASA NTRS1995

Computer simulation and performance assessment of the packet-data service of the Aeronautical Mobile Satellite Service (AMSS)

The ICAO Aeronautical Mobile Communications Panel (AMCP) completed the drafting of the Aeronautical Mobile Satellite Service (AMSS) Standards and Recommended Practices (SARP's) and the associated Guidance Material and submitted these documents to ICAO Air Navigation Commission (ANC) for ratification in May 1994. This effort, encompassed an extensive, multi-national SARP's validation. As part of this activity, the US Federal Aviation Administration (FAA) sponsored an effort to validate the SARP's via computer simulation. This paper provides a description of this effort. Specifically, it describes: (1) the approach selected for the creation of a high-fidelity AMSS computer model; (2) the test traffic generation scenarios; and (3) the resultant AMSS performance assessment. More recently, the AMSS computer model was also used to provide AMSS performance statistics in support of the RTCA standardization activities. This paper describes this effort as well.

Ferzali, Wassim↗
NASA NTRS1989

Fiber optic voice/data network

An asynchronous, high-speed, fiber optic local area network originally developed for tactical environments with additional benefits for other environments such as spacecraft, and the like. The network supports ordinary data packet traffic simultaneously with synchronous T1 voice traffic over a common token ring channel; however, the techniques and apparatus of this invention can be applied to any deterministic class of packet data networks, including multitier backbones, that must transport stream data (e.g., video, SAR, sensors) as well as data. A voice interface module parses, buffers, and resynchronizes the voice data to the packet network employing elastic buffers on both the sending and receiving ends. Voice call setup and switching functions are performed external to the network with ordinary PABX equipment. Clock information is passed across network boundaries in a token passing ring by preceeding the token with an idle period of non-transmission which allows the token to be used to re-establish a clock synchronized to the data. Provision is made to monitor and compensate the elastic receiving buffers so as to prevent them from overflowing or going empty.

Bergman, Larry A.↗
NASA NTRS1989

Standard services for the capture, processing, and distribution of packetized telemetry data

Standard functional services for the capture, processing, and distribution of packetized data are discussed with particular reference to the future implementation of packet processing systems, such as those for the Space Station Freedom. The major functions are listed under the following major categories: input processing, packet processing, and output processing. A functional block diagram of a packet data processing facility is presented, showing the distribution of the various processing functions as well as the primary data flow through the facility.

Stallings, William H.↗
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.↗
NASA NTRS2007

Digital Multicasting of Multiple Audio Streams

The Mission Control Center Voice Over Internet Protocol (MCC VOIP) system (see figure) comprises hardware and software that effect simultaneous, nearly real-time transmission of as many as 14 different audio streams to authorized listeners via the MCC intranet and/or the Internet. The original version of the MCC VOIP system was conceived to enable flight-support personnel located in offices outside a spacecraft mission control center to monitor audio loops within the mission control center. Different versions of the MCC VOIP system could be used for a variety of public and commercial purposes - for example, to enable members of the general public to monitor one or more NASA audio streams through their home computers, to enable air-traffic supervisors to monitor communication between airline pilots and air-traffic controllers in training, and to monitor conferences among brokers in a stock exchange. At the transmitting end, the audio-distribution process begins with feeding the audio signals to analog-to-digital converters. The resulting digital streams are sent through the MCC intranet, using a user datagram protocol (UDP), to a server that converts them to encrypted data packets. The encrypted data packets are then routed to the personal computers of authorized users by use of multicasting techniques. The total data-processing load on the portion of the system upstream of and including the encryption server is the total load imposed by all of the audio streams being encoded, regardless of the number of the listeners or the number of streams being monitored concurrently by the listeners. The personal computer of a user authorized to listen is equipped with special- purpose MCC audio-player software. When the user launches the program, the user is prompted to provide identification and a password. In one of two access- control provisions, the program is hard-coded to validate the user s identity and password against a list maintained on a domain-controller computer at the MCC. In the other access-control provision, the program verifies that the user is authorized to have access to the audio streams. Once both access-control checks are completed, the audio software presents a graphical display that includes audiostream-selection buttons and volume-control sliders. The user can select all or any subset of the available audio streams and can adjust the volume of each stream independently of that of the other streams. The audio-player program spawns a "read" process for the selected stream(s). The spawned process sends, to the router(s), a "multicast-join" request for the selected streams. The router(s) responds to the request by sending the encrypted multicast packets to the spawned process. The spawned process receives the encrypted multicast packets and sends a decryption packet to audio-driver software. As the volume or muting features are changed by the user, interrupts are sent to the spawned process to change the corresponding attributes sent to the audio-driver software. The total latency of this system - that is, the total time from the origination of the audio signals to generation of sound at a listener s computer - lies between four and six seconds.

Macha, Mitchell↗
NASA NTRS1988

Implementation of a tactical voice/data network over FDDI

An asynchronous high-speed fiber-optic local-area network is described that simultaneously supports packet data traffic with synchronous TI voice traffic over a standard asynchronous FDDI (fiber distributed data interface) token-ring channel. A voice interface module was developed that parses, buffers, and resynchronizes the voice data to the packet network. The technique is general, however, and can be applied to any deterministic class of networks, including multitier backbones. In addition, the higher layer packet data protocols may operate independently of those for the voice, thereby permitting great flexibility in reconfiguring the network. Voice call setup and switching functions are performed external to the network with PABX equipment.

Bergman, L. A.↗
NASA NTRS1989

Aeronautical mobile TDMA/MCTDMA system

A multiple carrier Time Division Multiple Access (TDMA) system capable of supporting voice, stream data, and packet data traffic between aircraft and ground terminals is presented. Demand assignment permits efficient resource sharing for voice and stream data. The bandwidth efficiency of uncoded A Quadrature Phase Shift Keying (AQPSK) is 1 bps/Hz. High time efficiency (approximately equals 83 percent) is achieved through the use of symbol synchronous TDMA. Demodulation is achieved without loop hang-up while requiring only a 16 symbol preamble each burst. A concatenated coding system provides reliable transmission under multipath conditions.

Magill, Thomas↗
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.↗
NASA NTRS2005

Encryption for Remote Control via Internet or Intranet

A data-communication protocol has been devised to enable secure, reliable remote control of processes and equipment via a collision-based network, while using minimal bandwidth and computation. The network could be the Internet or an intranet. Control is made secure by use of both a password and a dynamic key, which is sent transparently to a remote user by the controlled computer (that is, the computer, located at the site of the equipment or process to be controlled, that exerts direct control over the process). The protocol functions in the presence of network latency, overcomes errors caused by missed dynamic keys, and defeats attempts by unauthorized remote users to gain control. The protocol is not suitable for real-time control, but is well suited for applications in which control latencies up to about 0.5 second are acceptable. The encryption scheme involves the use of both a dynamic and a private key, without any additional overhead that would degrade performance. The dynamic key is embedded in the equipment- or process-monitor data packets sent out by the controlled computer: in other words, the dynamic key is a subset of the data in each such data packet. The controlled computer maintains a history of the last 3 to 5 data packets for use in decrypting incoming control commands. In addition, the controlled computer records a private key (password) that is given to the remote computer. The encrypted incoming command is permuted by both the dynamic and private key. A person who records the command data in a given packet for hostile purposes cannot use that packet after the public key expires (typically within 3 seconds). Even a person in possession of an unauthorized copy of the command/remote-display software cannot use that software in the absence of the password. The use of a dynamic key embedded in the outgoing data makes the central-processing unit overhead very small. The use of a National Instruments DataSocket(TradeMark) (or equivalent) protocol or the User Datagram Protocol makes it possible to obtain reasonably short response times: Typical response times in event-driven control, using packets sized .300 bytes, are <0.2 second for commands issued from locations anywhere on Earth. The protocol requires that control commands represent absolute values of controlled parameters (e.g., a specified temperature), as distinguished from changes in values of controlled parameters (e.g., a specified increment of temperature). Each command is issued three or more times to ensure delivery in crowded networks. The use of absolute-value commands prevents additional (redundant) commands from causing trouble. Because a remote controlling computer receives "talkback" in the form of data packets from the controlled computer, typically within a time interval < or =1 s, the controlling computer can re-issue a command if network failure has occurred. The controlled computer, the process or equipment that it controls, and any human operator(s) at the site of the controlled equipment or process should be equipped with safety measures to prevent damage to equipment or injury to humans. These features could be a combination of software, external hardware, and intervention by the human operator(s). The protocol is not fail-safe, but by adopting these safety measures as part of the protocol, one makes the protocol a robust means of controlling remote processes and equipment by use of typical office computers via intranets and/or the Internet.

Lineberger, Lewis↗
NASA NTRS1983

An end-to-end data system for the Gamma-Ray Observatory

A data system, which includes parts in the orbiting Gamma-Ray Observatory and in its associated ground system, has been designed to rapidly deliver autonomous, packeted data to the science users. Data autonomy means all of the data, including auxiliary data, necessary for processing is included in the data packet that leaves the spacecraft. The data packets leaving the spacecraft remain unopened until they reach the user. Handling the data on a packet rather than a byte level allows simpler and generic software. The data goes through the system more quickly. This in turn reduces cost.

Hrastar, J.↗