Electrical computers and digital data processing systems: input/ – Input/output data processing – Input/output data buffering
Reexamination Certificate
1997-10-29
2001-01-23
Teska, Kevin J. (Department: 2763)
Electrical computers and digital data processing systems: input/
Input/output data processing
Input/output data buffering
C370S392000
Reexamination Certificate
active
06178470
ABSTRACT:
TECHNICAL FIELD
This invention relates generally to apparatus for processing digital data and more particularly to a service processor for processing a serial data stream such as that received from an airborne vehicle such as a spacecraft.
BACKGROUND ART
Airborne vehicles, such as spacecraft have been used to both relay data and to generate data. When functioning as a relay, it may receive data from a source, such as a ground transmitter, i.e., on an up-link, store the data, and then transmit the data, on instruction, to a ground station, i.e., on a return- or down-link. When functioning as a data generator, the spacecraft may have one or more instruments functioning as sensors with the sensor information being stored and transmitted, on instruction, to a ground station on a down-link. With a plurality of instruments, the sensor information will be multiplexed. Whether functioning as a relay or a generator, with or without multiplexing, the spacecraft will typically convert and store information in binary form and thereafter down-link a serial data stream. The serial data stream contains the binary information that is embedded in the transmitted RF signal through a number of modulation schemes.
Regardless of spacecraft configuration and design particulars, a ground station receiving spacecraft transmissions will be receiving a continuous RF serial data stream which must undergo signal processing of some kind to extract information from the data stream. The configuration and complexity of the signal processing will be determined by the complexity of the serial data stream signal.
Relatively inexpensive, less complex systems include a low data rate transmitter, transmitting a signal in the order of kilo bits per second (Kbps), to a spacecraft. The transmitter signal includes transmitter identification (ID). The spacecraft functions to receive, store, and “dump” (transmit) on command. The spacecraft receiver typically will include demodulation and error correction after which the data is stored until the dump instruction is received. Thereafter, the spacecraft will transmit to a ground station. These spacecraft will often transmit at Ka, Ku, S or X bands, where the low data rate information is embedded on the RF employing simple phase modulation. In some cases, more sophisticated modulation schemes are employed, such as binary phase shift keyed (BPSK) or quadrature phase shift keyed (QPSK) modulation. These spacecraft are typically in low earth orbit (LEO) where the orbit is known and transmissions to the spacecraft from the data source, e.g., ground, and from the spacecraft to the ground station, can be appropriately timed. Some of these systems employ relay satellites as well.
When the spacecraft transmission, including the ID, is received at the ground station, it must be suitably processed. While ground stations vary in terms of complexity, modern ground stations normally will contain some common features. These would include, in the order of the direction of signal flow, an antenna followed by a receiver with an RF gain stage, down conversion to an intermediate frequency and a demodulation stage. The output of the demodulator would then be fed to a bit synchronizer to synchronize the bit stream to a system clock. At this point, a serial data stream exists that is, in essence, the same as that received at the ground station, except that it is at a much lower frequency, i.e., a binary series of ones and zeros. As yet, however, no useful information can be extracted because the beginning and end of the encoded information is unknown. The return- or down-link processing from this point generally involves the extraction of framed digital data from the bit stream, correction of the fame to frame data, validation of the protocol structures within the frame, and the extraction of user data. For these purposes, the data stream is inputted into a frame synchronizer followed by frame error detector and corrector, often a Reed-Solomon type, and thereafter followed by a service processor.
The frame synchronizer determines the telemetry frame boundaries from the bit stream by detecting sync markers embedded in the bit stream. The output of the frame synchronizer will then be inputted to the error detection and correction circuitry that detects and corrects frame-to-frame errors caused by transmission disturbances, in essence, with parity checks. Thus, the output at this point is a corrected telemetry frame that, as yet, has no extraction of any particular data. For this purpose, the corrected telemetry frames are inputted to a service processor. While a service processor may perform a number of functions, its basic function is packet extraction which refers to the extraction, and possible reconstruction, of packets of data from the frame synchronizer. A packet is, by definition, associated with a single instrument or other signal source. A packet of data not only contains data related to a single instrument or other source, it contains “overhead” data relating to the source. The overhead data includes such things as packet length as well as spacecraft and application IDs from which the particular source ID may be derived. These IDs are contained in a transfer frame and it is the information in the transfer frame that makes it possible for the service processor, the subject of the instant application, to extract packets relating to a given, predetermined source at a given time. More precisely, a transfer frame contains information pertaining to a transmitting spacecraft as well as a data area containing data from a particular instrument or other source. Spacecraft information includes spacecraft and channel sequence identifiers. Telemetry ground stations use the channel sequence count to check for the receipt of all data from a specific channel. Specifically, the ground station service processors use the spacecraft and instrument IDs and the sequence count to check for errors in terms of the proper receipt of data.
Prior to the 1980's, the National Aeronautics and Space Administration (NASA) did not have standards for data transmission formats. Each spacecraft mission had its own protocol. The Consultative Committee on Space Data Systems (CCSDS) was formed to develop a set of recommended space data system standards and these were implemented in the mid-to-late 1980's. These standards impacted the design of both frame synchronizers and service processors. The last set of standards published by the Committee was in a document entitled “Advanced Orbiting Systems, Networks and Data Links: Architectural Specification,” CCSDS 701.o-B-2, Blue Book, November 1992. This document is on the Internet and is generally known to those involved in spacecraft systems design.
Service processing was implemented with a reliance on software. Both the real time data path as well as the decision making process were completely embedded in software that functioned to extract packets of data with given IDs and then carry out the particular algorithms for processing that data The hardware portion of the processor was responsible for data movement or routing. This implementation was capable of processing 100's of Kbps in real time. This kind of software implementation is still sufficient for current, inexpensive, low data rate spacecraft. The improvement in related hardware has not significantly improved the use of these software based service processors with the higher data rate systems. The processing of the frame data was, in essence, all accomplished by inherently slow serial operations. In addition to packet extraction and algorithm application to the data, service processors detect packet errors and provide the option of using or not using the data. There is no error correction function associated with service processors.
One of the significant problems with the prior art architecture is the low bandwidth utilization of the data path. This is due to the slow response time of software embedded decision making algorithms. For each packet, the fields must be extracted from the data path and analyze
Knox Lonnie A.
Lehmann Eileen A.
Teska Kevin J.
The United States of America as represented by the Administrator
LandOfFree
Chip for CCSDS compatible serial data streams does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Chip for CCSDS compatible serial data streams, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Chip for CCSDS compatible serial data streams will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2496317