Communication standards, who needs them?
Explore the source record for details and available documents.
CCSDS standards communications space data systems↗
SEARCH · Engineering Papers
Results for “CCSDS data standards”
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.
Message transfer service for space applications
Explore the source record for details and available documents.
CCSDS standards communications space data systems↗
Telemetry-Based Ranging
A telemetry-based ranging scheme was developed in which the downlink ranging signal is eliminated, and the range is computed directly from the downlink telemetry signal. This is the first Deep Space Network (DSN) ranging technology that does not require the spacecraft to transmit a separate ranging signal. By contrast, the evolutionary ranging techniques used over the years by NASA missions, including sequential ranging (transmission of a sequence of sinusoids) and PN-ranging (transmission of a pseudo-noise sequence) whether regenerative (spacecraft acquires, then regenerates and retransmits a noise-free ranging signal) or transparent (spacecraft feeds the noisy demodulated uplink ranging signal into the downlink phase modulator) relied on spacecraft power and bandwidth to transmit an explicit ranging signal. The state of the art in ranging is described in an emerging CCSDS (Consultative Committee for Space Data Systems) standard, in which a pseudo-noise (PN) sequence is transmitted from the ground to the spacecraft, acquired onboard, and the PN sequence is coherently retransmitted back to the ground, where a delay measurement is made between the uplink and downlink signals. In this work, the telemetry signal is aligned with the uplink PN code epoch. The ground station computes the delay between the uplink signal transmission and the received downlink telemetry. Such a computation is feasible because symbol synchronizability is already an integral part of the telemetry design. Under existing technology, the telemetry signal cannot be used for ranging because its arrival-time information is not coherent with any Earth reference signal. By introducing this coherence, and performing joint telemetry detection and arrival-time estimation on the ground, a high-rate telemetry signal can provide all the precision necessary for spacecraft ranging.
Hamkins, Jon↗
CCSDS File Delivery Protocol (CFDP): Why it's Useful and How it Works
Reliable delivery of data products is often required across space links. For example, a NASA mission will require reliable delivery of images produced by an on-board detector. Many missions have their own (unique) way of accomplishing this, requiring custom software. Many missions also require manual operations (e.g. the telemetry receiver software keeps track of what data is missing, and a person manually inputs the appropriate commands to request retransmissions). The Consultative Committee for Space Data Systems (CCSDS) developed the CCSDS File Delivery Protocol (CFDP) specifically for this situation. CFDP is an international standard communication protocol that provides reliable delivery of data products. It is designed for use across space links. It will work well if run over the widely used CCSDS Telemetry and Telecommand protocols. However, it can be run over any protocol, and will work well as long as the underlying protocol delivers a reasonable portion of the data. The CFDP receiver will autonomously determine what data is missing, and request retransmissions as needed. The CFDP sender will autonomously perform the requested transmissions. When the entire data product is delivered, the CFDP receiver will let the CFDP sender know that the transaction has completed successfully. The result is that custom software becomes standard, and manual operations become autonomous. This paper will consider various ways of achieving reliable file delivery, explain why CFDP is the optimal choice for use over space links, explain how the core protocol works, and give some guidance on how to best utilize CFDP within various mission scenarios. It will also touch on additional features of CFDP, as well as other uses for CFDP (e.g. the loading of on-board memory and tables).
Ray, Tim↗
NASA Near Earth Network (NEN), Deep Space Network (DSN) and Space Network (SN) Support of CubeSat Communications
There has been a historical trend to increase capability and drive down the Size, Weight and Power (SWAP) of satellites and that trend continues today. Small satellites, including systems conforming to the CubeSat specification, because of their low launch and development costs, are enabling new concepts and capabilities for science investigations across multiple fields of interest to NASA. NASA scientists and engineers across many of NASAs Mission Directorates and Centers are developing exciting CubeSat concepts and welcome potential partnerships for CubeSat endeavors. From a communications and tracking point of view, small satellites including CubeSats are a challenge to coordinate because of existing small spacecraft constraints, such as limited SWAP and attitude control, low power, and the potential for high numbers of operational spacecraft. The NASA Space Communications and Navigation (SCaN) Programs Near Earth Network (NEN), Deep Space Network (DSN) and the Space Network (SN) are customer driven organizations that provide comprehensive communications services for space assets including data transport between a missions orbiting satellite and its Mission Operations Center (MOC). The NASA NEN consists of multiple ground antennas. The SN consists of a constellation of geosynchronous (Earth orbiting) relay satellites, named the Tracking and Data Relay Satellite System (TDRSS). The DSN currently makes available 13 antennas at its three tracking stations located around the world for interplanetary communication. The presentation will analyze how well these space communication networks are positioned to support the emerging small satellite and CubeSat market. Recognizing the potential support, the presentation will review the basic capabilities of the NEN, DSN and SN in the context of small satellites and will present information about NEN, DSN and SN-compatible flight radios and antenna development activities at the Goddard Space Flight Center (GSFC) and across industry. The presentation will review concepts on how the SN multiple access capability could help locate CubeSats and provide a low-latency early warning system. The presentation will also present how the DSN is evolving to maximize use of its assets for interplanetary CubeSats. The critical spectrum-related topics of available and appropriate frequency bands, licensing, and coordination will be reviewed. Other key considerations, such as standardization of radio frequency interfaces and flight and ground communications hardware systems, will be addressed as such standardization may reduce the amount of time and cost required to obtain frequency authorization and perform compatibility and end-to-end testing. Examples of standardization that exist today are the NASA NEN, DSN and SN systems which have published users guides and defined frequency bands for high data rate communication, as well as conformance to CCSDS standards. The workshop session will also seek input from the workshop participants to better understand the needs of small satellite systems and to identify key development activities and operational approaches necessary to enhance communication and navigation support using NASA's NEN, DSN and SN.
Telecommunication↗
Standardization activity for the spacecraft onboard interfaces
The Consultative Committee for Space Data Systems (CCSDS) is an international organization of national space agencies that is organized to promote theinterchange of space related information. CCSDS is branching out to provide new standards to enhanced reuse of spacecraft equipment and software onboard of a spacecraft. This effort is know as Spacecraft Onboard Interface (SOIF). SOIF expects that these standards will be well used within the space community, and that they will be based on the well-known Internet protocols. This paper will provide a description of the SOIF work by reviewing this work with three orthogonal views. The Services View describes the data communications services that are provided to the users. The Interoperability view provides a description to users on how to use SOIF to interchange between different spacecraft data busses. And finally, the Protocol view, describes the protocols and services that are to be implemented in order to provide the users with the advantages of the SOIF architecture. This paper will give the reader an excellent introduction to the work of the international SOIF team.
Spacecraft interfaces standard interfaces CCSDS↗
The CCDS Data Compression Recommendations: Development and Status
The Consultative Committee for Space Data Systems (CCSDS) has been engaging in recommending data compression standards for space applications. The first effort focused on a lossless scheme that was adopted in 1997. Since then, space missions benefiting from this recommendation range from deep space probes to near Earth observatories. The cost savings result not only from reduced onboard storage and reduced bandwidth, but also in ground archive of mission data. In many instances, this recommendation also enables more science data to be collected for added scientific value. Since 1998, the compression sub-panel of CCSDS has been investigating lossy image compression schemes and is currently working towards a common solution for a single recommendation. The recommendation will fulfill the requirements for remote sensing conducted on space platforms.
Yeh, Pen-Shu↗
Applying Registry Services to Spaceflight Technologies to Aid in the Assignment of Assigned Numbers to Disparate Systems and their Technologies to Further Enable Interoperability
To date very little effort has been made to provide interoperability between various space agency projects. To effectively get to the Moon and beyond systems must interoperate. To provide interoperability, standardization and registries of various technologies will be required. These registries will be created as they relate to space flight. With the new NASA Moon/Mars initiative, a requirement to standardize and control the naming conventions of very disparate systems and technologies is emerging. The need to provide numbering to the many processes, schemas, vehicles, robots, space suits and technologies (e.g. versions), to name a few, in the highly complex Constellation initiative is imperative. The number of corporations, developer personnel, system interfaces, people interfaces will require standardization and registries on a scale not currently envisioned. It would only take one exception (stove piped system development) to weaken, if not, destroy interoperability. To start, a standardized registry process must be defined that allows many differing engineers, organizations and operators the ability to easily access disparate registry information across numerous technological and scientific disciplines. Once registries are standardized the need to provide registry support in terms of setup and operations, resolution of conflicts between registries and other issues will need to be addressed. Registries should not be confused with repositories. No end user data is "stored" in a registry nor is it a configuration control system. Once a registry standard is created and approved, the technologies that should be registered must be identified and prioritized. In this paper, we will identify and define a registry process that is compatible with the Constellation initiative and other non related space activities and organizations. We will then identify and define the various technologies that should use a registry to provide interoperability. The first set of technologies will be those that are currently in need of expansion namely the assignment of satellite designations and the process which controls assignments. Second, we will analyze the technologies currently standardized under the Consultative Committee for Space Data Systems (CCSDS) banner. Third, we will analyze the current CCSDS working group and Birds of a Feather (BoF) activities to ascertain registry requirements. Lastly, we will identify technologies that are either currently under the auspices of another standards body or technologies that are currently not standardized. For activities one through three, we will provide the analysis by either discipline or technology with rationale, identification and brief description of requirements and precedence. For activity four, we will provide a list of current standards bodies e.g. IETF and a list of potential candidates.
Bradford, Robert N.↗
Multi-User Space Link Extension (SLE) System
The Multi-User Space (MUS) Link Extension system, a software and data system, provides Space Link Extension (SLE) users with three space data transfer services in timely, complete, and offline modes as applicable according to standards defined by the Consultative Committee for Space Data Systems (CCSDS). MUS radically reduces the schedule, cost, and risk of implementing a new SLE user system, minimizes operating costs with a lights-out approach to SLE, and is designed to require no sustaining engineering expense during its lifetime unless changes in the CCSDS SLE standards, combined with new provider implementations, force changes. No software modification to MUS needs to be made to support a new mission. Any systems engineer with Linux experience can begin testing SLE user service instances with MUS starting from a personal computer (PC) within five days. For flight operators, MUS provides a familiar-looking Web page for entering SLE configuration data received from SLE. Operators can also use the Web page to back up a space mission's entire set of up to approximately 500 SLE service instances in less than five seconds, or to restore or transfer from another system the same amount of data from a MUS backup file in about the same amount of time. Missions operate each MUS SLE service instance independently by sending it MUS directives, which are legible, plain ASCII strings. MUS directives are usually (but not necessarily) sent through a TCP-IP (Transmission Control Protocol Internet Protocol) socket from a MOC (Mission Operations Center) or POCC (Payload Operations Control Center) system, under scripted control, during "lights-out" spacecraft operation. MUS permits the flight operations team to configure independently each of its data interfaces; not only commands and telemetry, but also MUS status messages to the MOC. Interfaces can use single- or multiple-client TCP/IP server sockets, TCP/IP client sockets, temporary disk files, the system log, or standard in, standard out, or standard error as applicable. By defining MUS templates in ASCII, the flight operations team can include any MUS system variable in telemetry or command headers or footers, and/or in status messages. Data fields can be arranged within messages in different sequences, according to the mission s needs. The only constraints imposed are on the format of MUS directive strings, and some bare minimum logical requirements that must be met in order for MUS to read the mission control center's spacecraft command inputs. The MUS system imposes no limits or constraints on the numbers and combinations of missions and SLE service instances that it will support simultaneously. At any time, flight operators may add, change, delete, bind, connect, or disconnect.
Perkins, Toby↗
The Evolution of the CCSDS Orbit Data Messages
The Consultative Committee for Space Data Systems (CCSDS) Orbit Data Messages (ODM) is undoubtedly the most successful and widely infused international standard developed by the CCSDS Navigation Working Group (NavWG). In 2004, the first version of the ODM was published after a development period of several years; before this, there was no CCSDS or ISO standard for the representation of a spacecraft trajectory. This paper will describe in detail the evolution of the CCSDS ODM through its several versions past, present, and future; its infusion into spacecraft operations in many if not most of the Earth's major space agencies; and some of the growing number of applications in which it is being utilized.
Oltrogge, Daniel L.↗
The behavior of a Costas loop in the presence of space telemetry signals
The telemetry modulation index, telemetry bit rate, subcarrier waveform, and subcarrier frequency are shown to be the key system parameters that contribute to the performance degradation of a Costas loop in the presence of space telemetry signals. The effects of the Doppler in the loop are also investigated. The results of this study were input to the Consultative Committee for Space Data Systems (CCSDS) for consideration in the future standard suppressed-carrier space telemetry system.
Nguyen, T. M.↗
Overview of the Current CCSDS Program of Work
This viewgraph presentation gives an overview of the Consultative Committee for Space Data Systems (CCSDS) program of work in space standardization.
space mission interoperability↗
Characterization of a Photon Counting Test Bed for Space to Ground Optical Pulse Position Modulation Communications Links
The National Aeronautics and Space Administration (NASA) Glenn Research Center (GRC) has developed a laboratory transmitter and receiver prototype of a space to ground optical communications link. The system is meant to emulate future deep space optical communication links, such as the first crewed flight of Orion, in which the transmitted laser is modulated using pulse position modulation and the receiver is capable of detecting single photons. The transmitter prototype consists of a software defined radio, a high extinction ratio electro-optic modulator system, and 1550 nm laser. The receiver is a scalable concept and utilizes a single-pixel array of fiber coupled superconducting nanowire single photon detectors. The transmit and receive waveforms follow the Consultative Committee for Space Data Systems (CCSDS) Optical Communications High Photon Efficiency Standard. This paper describes the transmitter and receiver prototypes as well as the system test configuration. System level tests results are presented and compared to predictions from software simulations.
Nappier, Jennifer M.↗
Characterization of a Photon Counting Test Bed for Space to Ground Optical Pulse Position Modulation Communications Links
The National Aeronautics and Space Administration (NASA) Glenn Research Center (GRC) has developed a laboratory transmitter and receiver prototype of a space-to-ground optical communications link. The system is meant to emulate future deep space optical communication links, such as the first crewed flight of Orion, in which the transmitted laser is modulated using pulse position modulation and the receiver is capable of detecting single photons. The transmitter prototype consists of a software defined radio, a high extinction ratio electro-optic modulator system, and a 1550 nm laser. The receiver is a scalable concept and utilizes a single-pixel array of fiber coupled superconducting nanowire single photon detectors. The transmit and receive waveforms follow the Consultative Committee for Space Data Systems (CCSDS) Optical Communications Coding and Synchronization Standard. A software model of the optical transmitter and receiver has also been implemented to predict performance of the optical test bed. This paper describes the transmitter and receiver prototypes as well as the system test configuration. System level tests results are presented and shown to align with predictions from software simulations. The validated software model can be used to in the future to reduce the design cycle of optical communications systems.
software defined radio↗
Latest Status of the CCSDS Optical Communications Working Group
International civil space agencies around the world are working together in the Interagency Operation Advisory Group (IOAG) and the Consultative Committee for Space Data Systems (CCSDS) to develop interoperability architectures and standards for space communications. Within CCSDS, there is a working group dedicated on developing recommendations and standards for optical communications. These standards include recommendations for the physical layer, coding and synchronization layer, and best practices for measuring and monitoring atmospheric conditions and operating optical links. The working group has developed standards for both Near Earth and deep space robotic and hum exploration missions. The standards generally address both free space links between spacecraft and free space links between spacecraft and ground. This paper will provide an overview and update on the set of standards the CCSDS Optical Communications Working Group has developed
Bernard L Edwards↗
A Real-Time Optical Ground Receiver for Photon Starved Environments
The National Aeronautics and Space Administration (NASA) Glenn Research Center (GRC) has developed a photon-counting optical ground receiver for pulse-position modulated signals. The real-time receiver system includes a fiber interconnect, superconducting nanowire single-photon detectors (SNSPDs), and a real-time field programmable gate array (FPGA) based receiver. The fiber interconnect and SNSPDs are implemented with two different configurations. In the first, a 7-channel few-mode fiber photonic lantern couples the light from the telescope to 7 single-pixel few-mode fiber coupled SNSPDs. In the second configuration, a few-mode fiber couples light to a 16-pixel monolithic SNSPD array. The real-time FPGA-based receiver performs combining of up to 16 SNSPD channels, symbol timing recovery, demodulation, and decoding. The system is scalable with data rates ranging from 20 Mbps to 267 Mbps. It is compliant with the Consultative Committee for Space Data Systems (CCSDS) Optical Communications Coding and Synchronization Standard. This standard will be used in NASA deep space and other low photon flux missions, such as in the Orion Artemis-2 Optical Communications System (O2O) demonstration, planned for the first crewed flight of Orion. This paper describes the scalable real-time optical receiver system and presents characterization test results.
optical communications↗
A Real-Time Optical Ground Receiver for Photon Starved Environments
The National Aeronautics and Space Administration (NASA) Glenn Research Center (GRC) has developed a photon-counting optical ground receiver for pulse-position modulated signals. The real-time receiver system includes a fiber interconnect, superconducting nanowire single-photon detectors (SNSPDs), and a real-time field programmable gate array (FPGA) based receiver. The fiber interconnect and SNSPDs are implemented with two different configurations. In the first, a 7-channel few-mode fiber photonic lantern couples the light from the telescope to 7 single-pixel few-mode fiber coupled SNSPDs. In the second configuration, a few-mode fiber couples light to a 16-pixel monolithic SNSPD array. The real-time FPGA-based receiver performs combining of up to 16 SNSPD channels, symbol timing recovery, demodulation, and decoding. The system is scalable with data rates ranging from 20 Mbps to 267 Mbps. It is compliant with the Consultative Committee for Space Data Systems (CCSDS) Optical Communications Coding and Synchronization Standard. This standard will be used in NASA deep space and other low photon flux missions, such as in the Orion Artemis-2 Optical Communications System (O2O) demonstration, planned for the first crewed flight of Orion. This paper describes the scalable real-time optical receiver system and presents characterization test results.
optical communications↗
Transferring Files Between the Deep Impact Spacecrafts and the Ground Data System Using the CCSDS File Delivery Protocol (CFDP): A Case Study
The CCSDS File Delivery Protocol (CFDP) Standard could reshape ground support architectures by enabling applications to communicate over the space link using reliable-symmetric transport services. JPL utilized the CFDP standard to support the Deep Impact Mission. The architecture was based on layering the CFDP applications on top of the CCSDS Space Link Extension Services for data transport from the mission control centers to the ground stations. On July 4, 2005 at 1:52 A.M. EDT, the Deep Impact impactor successfully collided with comet Tempel 1. During the final 48 hours prior to impact, over 300 files were uplinked to the spacecraft, while over 6 thousand files were downlinked from the spacecraft using the CFDP. This paper uses the Deep Impact Mission as a case study in a discussion of the CFDP architecture, Deep Impact Mission requirements, and design for integrating the CFDP into the JPL deep space support services. Issues and recommendations for future missions using CFDP are also provided.
CCSDS File Delivery Protocol (CFDP)↗