Open access peer-reviewed chapter

Communication Subsystems for Satellite Design

Written By

Hung H. Nguyen and Peter S. Nguyen

Submitted: 16 December 2019 Reviewed: 25 May 2020 Published: 06 July 2020

DOI: 10.5772/intechopen.93010

From the Edited Volume

Satellite Systems - Design, Modeling, Simulation and Analysis

Edited by Tien Nguyen

Chapter metrics overview

2,163 Chapter Downloads

View Full Metrics

Abstract

The objective of this chapter is to provide a comprehensive end-to-end overview of existing communication subsystems residing on both the satellite bus and payloads. These subsystems include command and mission data handling, telemetry and tracking, and the antenna payloads for both command, telemetry and mission data. The function of each subsystem and the relationships to the others will be described in detail. In addition, the recent application of software defined radio (SDR) to advanced satellite communication system design will be looked at with applications to satellite development, and the impacts on how SDR will affect future satellite missions are briefly discussed.

Keywords

  • command and data handling subsystem (C&DHS)
  • telemetry and tracking
  • antenna payload
  • software defined radio (SDR)

1. Background and introduction

In the context of this chapter, a satellite is a spacecraft (SC) that orbits around a celestial body such as the earth. A spacecraft has several design constraints placed upon it before it can be placed in an orbit around the intended celestial body. First, satellite designs are limited in their mass and volume to fit on the launch vehicle that places them into orbit. Secondly, the mass and volume limits affect the size of the power system on the spacecraft; therefore, the amount of power available to the satellite is also limited. In addition, the space environment (thermal, radiation, atomic oxygen, space debris, micrometeoroids, etc.) imposes constraints on the design such as parts and material selection.

A spacecraft is consisted of two parts: the spacecraft bus and the payload (PL) [1, 2]. The spacecraft bus provides control of the satellite and support services to the mission payload, while the mission payload provides the mission part of the satellite including payload control, mission data processing, and mission data downlink dissemination. Examples of mission payloads (or payloads or PLs) are: scientific instruments, remote sensing instruments, navigation service transmitters, or communications equipment. A satellite may have one type of PL or a combination of payload types to accomplish its mission such as navigation, remote sensing, and communications. Shown below in Figure 1 is a typical imaging satellite used for the remote sensing mission. Note the clear separation between the spacecraft bus that provides solar power and maneuvering capability via thruster, while the payload consisting of the camera and supporting communication devices such as antennas and guidance devices such as star trackers.

Figure 1.

A typical satellite with bus and payload separation.

Regardless of the mission type1 and the payload that a spacecraft carries, a subsystem that must exist in all satellites is the communication subsystem that enables the spacecraft to communicate with the ground stations that control the satellite and to deliver the data that the mission requires. This chapter focuses on architecture and functionalities of the communications subsystem that usually resides on the satellite.

There are three specific segments shown in Figure 2 below that must work together for the larger overall system to provide communication, navigation, or any other type of missions:

  • The space segment consisting of all satellites and associated equipment required for the mission applications and the launch vehicles used to deliver those satellites to orbit.

  • The satellite control (or control) segment consisting of all the personnel, facilities, and equipment that are used to monitor and control all the assets in space. Practically, the control segment is also referred to as satellite ground segment because it is usually located on the ground.

  • The user segment consisting of all the individuals and groups who use and benefit from the data and services provided by the payloads of the satellite and the equipment that allows this use.

Figure 2.

The three main segments for satellite system.

Advertisement

2. Typical satellite major subsystems

In general, the space mission dictates the type of orbit2, satellite design and its expected life cycle, and its operational scenarios. The PL design includes dimensions, interfaces, weight, physical characteristics, and basic utility needs (e.g., power consumption), which usually influences spacecraft (SC) bus design. The PL is often a unique and one-of-a-kind design tailored to meet specific mission requirements, frequently relying heavily on newer technology, while the satellite bus has the supporting function, and as such relies largely on existing or modified hardware such as batteries, inertial devices, and star trackers. Since PLs and their missions vary widely, so is this satellite bus supporting role.

Traditionally, the PL is considered a subsystem of the satellite bus that is designed to generally satisfy the corresponding mission requirements. The PL operational requirements sometimes impose specific requirements on the satellite bus that must be satisfied for the PL to accomplish its mission. This interdependence between satellite bus and PL subsystems has historically resulted in many nonstandard interfaces developed and implemented by the incumbent spacecraft builders. As a result, the aerospace industry has been moving toward a more standardized and commodity satellite bus framework that can potentially result in a tremendous cost saving approach.

As shown in Figure 3 below, a satellite bus typically consists of the following subsystems: command and data handling subsystem (C&DHS); communications subsystem (CS); electrical power subsystem (EPS); propulsion subsystem (PS); thermal control subsystem (TCS); attitude control subsystem (ACS) also known as guidance, navigation and control (GNC) subsystem; structures and mechanics subsystem (S&MS); and life support subsystem for manned missions if required. The C&DHS will be described in detail below. The CS provides the satellite bus with the necessary communication functionalities to connect the user and ground segments to different satellite subsystems. The EPS provides the electrical power generation and distribution for various spacecraft subsystems. The PS provides maneuvers necessary for altitude, inclination adjustment, and momentum management adjustments. The TCS provides active thermal control from electrical heaters and actuators to control temperature ranges of equipment within specific ranges. The ACS provides proper pointing directions for the satellite subsystems, such as sun pointing for EPS to the solar arrays and earth pointing for CS. The S&MS provides the necessary mechanical structure to withstand launch loads by the launch vehicle, during orbital maneuvers, as well as loads imparted by entry into the atmosphere of earth or another planetary body.

Figure 3.

A typical satellite bus and payload subsystem.

On the other hand, a PL is tailored to a specific mission type. For example, a remote sensing satellite can have as its payload an electro-optical (EO) camera to take day-time pictures of the earth and then convert them to electrical signals that can be captured. Alternatively, the camera may also have infra-red (IR) sensors that enable the PL to see the earth at night, or microwave sensors that will let the PL “see” radio frequency (RF) signals from the earth at several radio frequencies (RFs). These sensors can be classified as passive or active, and each of them can be further classified as imaging or sounding3. Figure 4 below illustrates a generic imaging PL that will convert the sensor analog data into electrical signals that can be captured and transmitted to a ground station. Note the existence of a communication subsystem as part of this imaging payload.

Figure 4.

A typical and generic sensor payload.

Advertisement

3. Typical communications subsystems for satellite

In this section, the different typical modules of a satellite communication subsystem are discussed. In addition, the command and data handling subsystem, and command, telemetry and mission data processing subsystem will also be described in detail.

3.1 Antenna and RF front-end/back-end subsystems

At the physical layer, the communications subsystem starts with an antenna and the RF front-end transceiver. The antenna is the most important component of the communications subsystem where the electromagnetic (EM) signals are originated or received. The RF front-end/back-end is where the EM signal is being down/up-converted to baseband/RF signal to be demodulated/modulated for baseband signal recovery or downlink transmission, respectively. Figure 5 below depicts a typical transmitter and receiver (transceiver) chain with the modulation and demodulation (MODEM), followed by the RF front-end and the antennas. The baseband communications function is carried out by the MODEM, whereas the RF portion is handled in the transceiver, RF front-end, and antenna sections.

Figure 5.

Typical RF front-end chain.

Modulation is the name given to the process of impressing the wanted signal to be transported onto a radio frequency (RF) carrier, which is then conveyed over the satellite link and demodulated at the receiving terminal to extract the wanted signal from the carrier. Thus, modulation translates a baseband spectrum (at zero frequency) to a carrier spectrum (at RF range) and demodulation is the process of recovering the data at the receiver end of the link. Thus, the process requires a modulator and a demodulator, collectively known as a MODEM. The input to the modulator may require some initial processing such as filtering and amplitude limiting.

Before the RF signal is sent to the antenna, a traveling wave tube amplifier (TWTA) or solid-state power amplifier (SSPA) is needed to amplify the RF signal to a desired level for transmission. Conversely, after the RF signal is received by the antenna, a low noise amplifier (LNA) is needed to ensure that the received signal is brought up to the desired signal level with minimum noise before demodulation.

In addition to being lighter than TWTA, the achievable power efficiency for SSPAs is a major factor to support transmit phased arrays. Currently, the tube-based TWTA implementations are still the most cost-effective design, even though both options might be viable for lower power systems.

In increasing technical maturation over the years, the following types of spacecraft antennas have been used for satellite communications:

  1. Low-gain omni and squinted-beam antennas for large earth coverage.

  2. Increased gain types of satellite antennas (horn type and helix antennas) for medium earth coverage.

  3. Parabolic reflectors, including multi-beam antennas with multiple feed systems for multiple user and small area coverage.

  4. Deployable antennas, particularly to achieve more highly focused beams and support much high-gain multi-beam antennas.

  5. Phased array feed and phased array antennas for scanning and hopping beams.

  6. Optical communications systems, which have been used for intersatellite links and interplanetary communications, and increasingly being considered for earth-to-space systems.

In general, there are many different types of antennas, but the one most commonly associated with satellite communications is the parabolic dish antenna. These dish antennas have a narrow beam width, concentrating the energy of the radiated main beam into a smaller solid angle. This means more of the radiated energy reaches, or “illuminates,” the satellite when using a dish antenna as compared to an omnidirectional, or “omni” for short, antenna. An example of dish antenna used on satellite is shown below in Figure 6 for a Ku-band space to ground antenna (SGANT) mounted on the external stowage platform of the International Space Station (ISS).

Figure 6.

Example of a satellite dish antenna.

There are several factors driving the design and development of satellite antennas. These include the need to reuse frequency bands because of limited spectrum allocations; the need to have antennas that can operate at higher frequencies with higher bandwidth; and the desire to deploy higher gain antennas at the same time minimizing the required size, weight, and power (SWAP) constrains. In practice, there are substantially more SWAP constrains for satellite antennas than on the ground stations, and this results in several design trade-offs between the space and control/user segments.

For example, the GEO orbit allows a high gain antenna to be pointed at a satellite with a minimum of tracking. Thus, a large dish can be used and remain virtually stationary without tracking a satellite as it moves around in its orbit. On the other hand, a low earth orbit (LEO) satellite that can cross from horizon to horizon in a few seconds can result in ground antenna installations that can be quite complex and expensive. Consequently, trade-offs need to be made to support the mission parameters of the whole satellite network.

3.2 Command and data handling subsystem

The term “command and data handling subsystem” (C&DHS) was referred to as “On-board Computer” (OBC), which is a legacy of the past in which many satellite functions were performed by analog circuits with the help of an OBC. With the current shift toward the digital domain, the term OBC does not fully cover the topic anymore thus C&DHS is being used instead. An appropriate analogy to describe the C&DHS subsystem is to regard it as the brain and nervous system of the spacecraft.

The function of a C&DHS subsystem is to perform onboard processing and operations and internal communication [3, 4]. The task of managing the operations of the spacecraft subsystems is nowadays performed mostly by software in an autonomous manner and is generally categorized as onboard operations. The software is also responsible for preparing the data to be downlinked and handling any commands that are received from satellite operators on the ground. Lastly, the C&DHS facilitates and controls all internal communications (consisting of commands, telemetry, and tracking data) between the different satellite subsystems. The basic functions of the C&DHS can be summarized below:

  1. Receives commands from the command or user segment through the telemetry, tracking, and control (TT&C) subsystem.

  2. Decodes, executes, and/or distributes those commands to/from the onboard computer.

  3. Collects and formats telemetry data from all space vehicle (SV) units.

  4. Distributes telemetry for downlinking. Provides a platform for bus flight software (FSW).

  5. Additional functions include ranging processing for satellite tracking purpose, satellite timekeeping, computer health monitoring (watchdog), and security interfaces.

An overview of the architecture of C&DHS in a typical satellite is provided in Figure 7 below. In this figure, all components are connected to each other via a common low-speed data bus in red color, typically compliant with MIL-STD 1553 or other standards. Also shown is the data connection in blue from the C&DHS to other components, which is more customized and high-speed in nature depending on the design.

Figure 7.

Block diagram of a typical command and data handling subsystem.

The heart of the system is the C&DHS’ onboard computer (or OBC) that runs the software responsible for managing the onboard operations. The OBC is tightly linked to the electrical power subsystem (EPS). The main reason is the importance of the available and consumed power for managing onboard spacecraft operations. For instance, by continuously querying the EPS on the available power, the OBC can decide to turn off non-critical subsystems to prevent vital systems from shutting down from lack of power. Secondly, the OBC must be able to command the EPS to disable or enable different subsystems throughout the various phases of the mission. Since the amount of transmitted data between these two subsystems is small, a low-speed data link is sufficient, although there is a new trend to incorporate high-speed standard link such as SpaceWire4 to satisfy increasing demand for data volume.

The OBC is also responsible for receiving, interpreting, and executing commands from ground operators via the radio receiver. Using low-speed radio transmitters, the OBC also sends packets of housekeeping data, or telemetry, to the ground station. The purpose of the housekeeping data is to give the operators on the ground an overview of the spacecraft health and its general condition.

Some small satellites only have a single low-speed transmitter, so the housekeeping and payload data are combined over the same link. For larger satellites with payloads capable of producing vast amounts of data, a dedicated high-speed data link is used to store the data on an onboard storage system. When the satellites pass over a ground station, the OBC commands the high-speed radio transmitter to retrieve and transmit the previously stored payload data through another dedicated high-speed link from the onboard storage system. This approach frees the OBC from having to process large amounts of data and allows it to devote its internal resources for time critical operations and communicates with the PL and all other subsystems through the low-speed data links. This would include the requirements to retrieve information on the health, perform critical interventions as well as to command these subsystems to perform various actions according to the operational arrangement of the mission.

3.3 Typical command and telemetry processing subsystem

The telemetry, tracking, and control (TT&C) subsystem of a satellite provides a connection between the satellite (space segment) and the ground facilities (control or user segment). The purpose of the TT&C function is to ensure the satellite performs correctly. As part of the satellite bus, the TT&C subsystem is required for all satellites regardless of the mission type. The TT&C subsystem has three specific tasks that must be performed to ensure a successful mission:

  1. Telemetry: the collection, processing of health, and status data of all spacecraft subsystems, and the transmission of these data to the control segment on the ground. This requires not only a telemetry system on the spacecraft but also a global network of ground stations around the world, unless the satellite space network includes intersatellite links that can relay the data to designated satellite and downlink to the appropriate ground station. Figure 8 below illustrates the processing of telemetry data by the C&DHS. Here the different health information and status information sent from various subsystems are collected by the telemetry input interface, fed to the C&DHS processor, buffered, encrypted, and sent down to the ground station.

  2. Tracking: the determination of the satellite’s exact location by the control segment and where it is going via the reception, processing, and transmitting of ranging signals. This requires a ranging system on the spacecraft and a data collection ground network for this tracking function to work.

  3. Command and control: the reception and processing of commands for continuous operation of the satellite. Usually a ground system is required, although advanced spacecraft designs have evolved toward “autonomous operations” so that many of the control functions can be automated onboard and do not require ground intervention except under emergency conditions. A typical command processing scenario is illustrated in Figure 9 where serial command bit stream from the command receiver is received by the command input interface, where the relevant commands are extracted and sent to the appropriate subsystems via a serial or parallel interface.

Figure 8.

Telemetry processing by C&DHS.

Figure 9.

Command and control message processing by C&DHS.

3.4 Typical mission data processing subsystem for communication applications

For communications payload, the onboard switching systems are designed to make more efficient use of a satellite communication network, especially those that employ multi-beam technology that entails onboard switching to interconnect uplink and downlink beams with a high degree of efficiency.

Figure 10 below summarizes the functional block diagram of a channelized transponder processor assuming a digital implementation of the channelized transponder filtering and switching function. Any signal within the receiver bandwidth is down-converted to an intermediate frequency (IF) or baseband and digitally sampled. These samples are digitally filtered, stored, and routed to the switch port corresponding to the desired downlink beam. This routing is achieved by a simple readdressing of the stored digital samples within a common output buffer memory or by a more traditional digital switch implementation.

Figure 10.

Channelized processor for communications payload.

For most sensing payload and as shown in Figure 4 above, the sensor analog data are collected onboard, digitized, buffered if necessary, and transmitted down to ground station for processing. This is due to the complexity of sensing mission data processing and the lack of onboard computational power to accomplish these tasks. An example of onboard PL processing for passive electro-optical (EO) remote sensing is shown in Figure 11 below, where the reflected light from earth is passing through a combination of optical lenses and charge coupled device5 (CCD) whose output is an analog signal that would be conditioned by analog filters before being digitized, compressed, and sent down via a mission data downlink to the ground station for processing. There, the data are decompressed, and image is enhanced by appropriate algorithms and displayed for users.

Figure 11.

Onboard image processing for an EO application.

Typical data volume collected by sensing payload is large, and peak rates can produce data at much higher speeds than TT&C; thus, a separate downlink for mission data is needed. Depending on the system, this mission data downlink to a ground station can either be performed using a dedicated mission direct downlink, or indirectly via a relay broadband communications satellite. Sensing satellite can be positioned in GEO, MEO, or LEO orbits, and can have many possible mission data downlink architectures based on mission requirements. For example, a LEO sensing satellite can either buffer its mission data until within view of a dedicated ground station for downlink, or it can forward its mission data to a relay satellite that can ensure that the mission data can be downlinked to a designated ground station.

Another example of active remote sensing is a synthetic aperture radar (SAR) mission, where returned radar signals are collected onboard and sent to the ground to be correlated and form an image of the ground surface. This type of remote sensing does not heavily depend on sun light and other weather affects. Applications for SAR include agriculture, geology, geohazards, ice, oil spills, and flood monitoring. Several emerging applications such as forestry, ship detection, and others are possible [1]. An example of a SAR mission is the NASA-ISRO Synthetic Aperture Radar (NISAR) [5], which is a collaborative earth-science mission between NASA and the Indian Space Research Organization (ISRO). The sensing payload features an L-band SAR instrument and an S-band SAR instrument. The simultaneous dual-frequency radar system at peak rates will produce data at gigabit-per second speeds, which drives the data-volume requirements at a minimum of 35 Terabits per day of radar science data to the ground. This is a direct mission downlink system with three designated ground stations. The payload communication system uses a 70-cm high-gain antenna with two synchronized transmitters in a dual-polarization configuration with each transmitter providing 2.4 Gbps of coded data with an aggregate rate of 4.8 Gbps.

Advertisement

4. Software defined radio (SDR) and applications to satellite

Traditional communications systems are designed for and constrained to a specific waveform(s) operating over predetermined frequencies, bandwidths, and signal modulation types. This paradigm works well when the requirements and constraints of the communication link and network protocol are well understood prior to design.

As a result, most radios in today’s world have very dedicated uses. A car key fob is designed only to unlock or lock your car door, while a smart phone radio connects to the Internet through various wireless communication protocols. Although these examples vary in complexity of the hardware, they both cannot operate outside the confines of their physical layer implementation. Consequently, RF hardware with a narrow focus is not suitable for applications with a broader communication scope.

A single software defined radio (SDR) with a flexible RF front-end combined with modern computing power can be used for the above applications plus more. In addition, a radio with a flexible hardware and software architecture can also lead to more innovation in the communications industry. Because of the rapid development nature of software, an engineer or researcher can experiment with novel ideas and SDR waveforms that would not be achievable with a traditional radio.

SDR in the satellite communications industry has become a growing trend, particularly in the commercial and defense industries. In the following section, an overview of SDR will be given and applications of SDR in satellite communications will be discussed.

4.1 Overview of SDR

Before going into SDR basics, some of the SDR advantages are [6]:

  • Interoperability: an SDR can seamlessly communicate with incompatible radios, or work as a bridge between them. For example, different branches of the military and law enforcement can use many incompatible radios, thus hindering communications during joint operations. A single multichannel SDR can work with all these different radios and provide interoperability.

  • Efficient use of resources under varying conditions: for example, a low-power waveform can be selected if the radio is running low on battery, while a high-throughput waveform can be used to quickly download a file. This flexibility is one of the first reasons why SDR became popular.

  • Opportunistic frequency reuse in SDR using cognitive radio6 (CR) technology: if the “owner” (or primary user) of a spectrum band is not using it, an SDR-CR can “borrow” the spectrum until the owner comes back. This technique has the potential to dramatically increase efficient use of radio frequency spectrum.

  • Reduced obsolescence: an SDR can be field upgraded to support the latest communications standards. This capability is especially important to radio with long life cycles such as those in satellite communications.

  • Lower cost: a single SDR can be adapted for use in multiple markets and for multiple applications. For example, a single radio can be sold to cell phone and automobile manufacturers to significantly reduce cost.

  • Research and development: SDR can be used to implement many different advanced waveforms, e.g., code division multiplexing access (CDMA) or orthogonal frequency division multiplexing (OFDM), for real-time performance analysis. Performance studies can be conducted much faster and often with higher fidelity than simulations.

On the other hand, some of the disadvantages for SDR are:

  • Cost is the most common argument against SDR. A single key fob is based on a very inexpensive ASIC7; however SDR is heavily reliant on FPGA,8 which is much more expensive. This is even more significant for high-volume, low-margin consumer products.

  • The second most common argument against SDR is increased power consumption with increased DSP complexity and higher mixed-signal/RF bandwidth. Power consumption in an FPGA or GPP for flexible signal processing can easily be 10 times higher than in ASIC. Also, wideband analog-to-digital converters (ADCs), digital-to-analog converters (DACs), and RF front-ends consume more power than their narrowband equivalents.

  • Increased time and cost to implement the radio: it can take much more engineering effort to develop software/firmware for multiple waveforms than for one, especially if it must be compliant with a military standard such as JTRS9.

  • Changing specifications and requirements: this usually happens when the SDR design must support not only a set of baseline waveforms but also anticipate additional waveforms.

  • Increased schedule risks: since SDR is still a relatively new technology, it is more difficult to anticipate schedule problems. Also, it is difficult to thoroughly test the radio in all the supported and anticipated modes.

  • Limited technical scope: SDR only addresses the physical layer and will require cooperation from upper layers for throughput improvements.

4.1.1 SDR basics

The general definition for a SDR is a radio with some or all its physical layer behavior defined through means of software [7, 8]. SDRs are incredibly valuable devices as they allow the end user the ability to traverse the RF spectrum at variable sampling rates. The fundamental qualities that make up an SDR are the flexible specifications and the ability to transform the analog signal using digital signal processing (DSP).

A radio can be categorically separated into receivers and transmitters. For this section, the receiver implementation will be considered as it is generally more interesting and complex. A block diagram of an SDR receiver is shown below in Figure 12. The following sections will present the anatomy of the SDR that differentiates it from a traditionally designed radio.

Figure 12.

A block diagram of an SDR.

4.1.2 RF front-end

The purpose of the RF front-end (RFFE) is to isolate the desired signal received by the antenna from interference signals. To achieve this, the signal of interest must be brought down to lower frequency for digital conversion while mitigating the side effects from filtering during the frequency conversion process. A flexible RFFE for SDR must be designed so that the frequency and bandwidth are controllable by software. Depending on the system requirements and the available RF component specifications, there are several ways to achieve this.

One of the most common RFFE designs for analog radios is the heterodyne receiver. A heterodyne receiver, shown in Figure 13 below, works by mixing down the received signal from its carrier frequency to a lower intermediate frequency (IF). The signal at IF can now be more conveniently filtered, amplified, and processed. A super-heterodyne receiver uses a fixed IF that is lower than the carrier frequency but higher than the signal bandwidth and often uses two stages of down conversion to reduce the filtering requirements at each stage.

Figure 13.

Heterodyne receiver.

Another popular RF front-end architecture generally used for low-power applications is called zero-IF. A zero-IF receiver, shown in Figure 14 below, uses a single mixing stage with the local oscillator (LO) set directly to the desired carrier frequency to convert directly to baseband in-phase and quadrature signals. Because mixers tend to have high power consumption and only low-pass filters are required, the simpler zero-IF provides improved power efficiency over a heterodyne architecture. However, the zero-IF implementation is more susceptible to IQ imbalances of the in-phase and quadrature oscillators, which will produce anomalies in the signal constellation. LO leakage may also self-mix through the RF ports creating a large DC bias. Both issues can be corrected using digital signal processing.

Figure 14.

Zero-IF receiver.

The analog-to-digital converter (ADC) is responsible for converting a continuous-time signal to a discrete-time one. To translate signals from the analog to digital domain, an ADC must perform two fundamental steps: sampling and quantization. Sampling is the process of reading voltages at discrete-time intervals. Quantization is the process of converting these voltage readings into binary outputs. ADC performance can be evaluated based on various parameters, such as: signal-to-noise ratio (SNR), dynamic range, bit resolution, sampling rate, and power dissipation. The ADC dictates the DSP limitations of the SDR. Generally, the sampling rate should be at least twice the desired bandwidth of your signal. The ADC should be chosen to match the capability of your processor and specifications of the signals of interest.

4.1.3 Digital front-end (DFE)

The two main functions of a digital front-end are sample rate conversion (SRC) and channelization. Once a signal has become digitally converted, the samples need to be further primed for digital processing. Operating the ADC at a fixed rate simplifies its clock generation; however, it may be necessary to convert the sampling rate to match the sampling rate required to demodulate certain waveforms. Most wireless signals generally operate with specific symbol or chip rates that are specified by their respective standard. Depending on the RFFE design and signal type, channelization may be required to select the channel of interest.

SRC represents a classic sampling theorem problem. Converting sampling rates can introduce undesirable effects such as aliasing, an effect that causes frequency components to overlap. SRC can be achieved digitally through the processes of decimation and interpolation. To mitigate aliasing, decimation is performed by using an anti-aliasing filter followed by subsampling, which is essentially removing samples at certain intervals. Interpolation is a method of calculating values to add values in between samples. Channelization works by using digital down conversion, the process of digitally mixing down a signal to baseband with a numerically controlled oscillator.

4.1.4 Digital signal processing

SDRs have an array of devices to choose from for the required DSP application, each with their own strengths and weaknesses. An SDR may integrate multiple processor types and partition the signal processing chain to optimize each processor. The following criteria should be considered when evaluating the various processor types: flexibility, modularity, and performance. The three digital hardware choices this section will consider are the general-purpose processor (GPP), digital signal processor (DSP), and the field programmable gate array (FPGA).

A GPP is the typical microprocessor designed to handle a wide variety of generic tasks that can be found in your everyday personal computer. They are generally designed to have large instruction sets and highly capable of implementing and performing complex arithmetic tasks such as modulation/demodulation, filtering, fixed/floating point math, and encoding/decoding. Some commonly used GPP architectures are x86/64 and Advanced RISC Machine (ARM). The advantage of using a GPP is the wide availability, flexibility, and ease of programmability. Several GPP-based SDRs, such as Universal Software Radio Peripheral (USRP) and the LimeSDR, operate by digitizing the baseband signal and performing the required digital signal processing on computers. These types of SDRs are popular among university researchers and hobbyists due to the relative ease of obtaining and developing their applications.

Because the GPP was designed with such a broad focus, latency, speed, and power efficiency may be a limiting factor depending on the application. Many wireless communication standards have strict real-time and large processing bandwidth requirements that most modern CPUs cannot meet due to processor architecture and operating system design. .

A DSP is a microprocessor optimized for digital signal processing applications with the ability to be programmed with high-level languages. Although a GPP can contain much of the same functionality, the DSP performs the same digital signal processing operations more quickly and efficiently due to its reduced instruction set computer (RISC) architecture and parallel processing. The reduced instruction set limits the essentials but contains optimizations for common DSP operations such as multiply accumulate (MAC), filtering, matrix operations, and fast Fourier transform (FFT). DSPs are commonly sold in two variants: optimized for power efficiency and optimized for performance; and are used in applications such as base stations and edge devices. Power consumption is also minimized by reducing the silicon footprint that would be in GPPs sophisticated cache and peripheral subsystems.

Although DSPs have been commonly deployed in the past decades, they serve as a middle ground between GPPs and FPGAs with regard to flexibility, performance and efficiency. Field-programmable gate array (FPGA) offers more parallelism, higher data rates, and better power efficiency than DSP, but is not well suited for control applications, such as implementing the network/protocol stack. This is due to the limited amount of memory in FPGA and for this reason it is often paired with GPP.

A FPGA is an array of programmable hardware logic blocks, such as general logic, memory, and multiplier blocks, that are wired together via a reconfigurable interconnect to generate an integrated circuit for several designs with the ability to quickly switch between configurations. FPGA configurations are programmed using hardware description language (HDL), which is also used for ASIC. Because a FPGA functionality is defined at the hardware level and can be implemented using parallelism, it can perform DSP algorithms at much higher rates than DSPs and GPPs. FPGA consumes more power and requires more space than ASICs but provides more programmability and flexibility than ASIC. A big consideration for using FPGAs for SDR is the domain knowledge requirement for developers. Developing on FPGAs can be time consuming and require an extensive understanding of the target hardware architecture.

When the system requirements exceed the capabilities of a singular processor type, a comprehensive solution may include a combination of the above processor types. A common processing architecture in the defense industry comprises of a FPGA, DSP, and GPP. In this paradigm, the FPGA is responsible for high data rate signal processing tasks, such as sampling and filtering, the DSP handles demodulation and protocol, and the GPP performs control-related tasks, such as the user interface and algorithmic processing. Implementing such a system can become a complex management task to coordinate the processing flow; however, the system can benefit greatly by optimizing overall performance based on the strength of each processor.

4.2 Applications of SDR to satellites

For space applications, SDR has unique challenges such as extreme radiation and temperature environment, autonomous operational requirements, limitations on size, weight and power (SWAP), and the need for reduced development time and increased reliability in agile prototyping. In this section, recent applications of software defined radio to satellite, as well as the current status of radiation-hardened SDR components, are presented.

4.2.1 NASA STRS

Recognizing early on that a standard and open architecture is needed to encourage reuse and portability of software, NASA developed an open architecture specification for space and ground SDRs called the Space Telecommunications Radio System (STRS) [9]. From this standard, several compliant systems have been built and demonstrated in radios on the International Space Station (ISS) and several ground stations. It was also the intention of NASA that the STRS architecture should be used as baseline for many future NASA space communications technologies.

In a nutshell, the STRS standard consists of hardware, configurable hardware design, and software architectures with accompanying description, guidance, and requirements. The three main hardware functionalities are connected by the Hardware Interface Description10 (HID) and described and shown in Figure 15 below:

  1. General processing module (GPM) consists of the general-purpose processor; appropriate memory; spacecraft bus (e.g., MILSTD-1553, Space Wire); interconnection bus (e.g., PCI); and the components to support the configuration of the radio.

  2. Signal processing module (SPM) where signal processing is used to handle the transformation of digital signals into data packets. Its components include ASICs, FPGAs, DSPs, memory, and connection fabric/bus (e.g., PCI, flex-fabric).

  3. RF module (RFM) handles the RF functionality to transmit/receive the appropriate digital signal. Its components include RF switches, digital-to-analog converter (DAC), analog-to-digital converter (ADC), diplexer, filters, low-noise amplifiers (LNAs), and power amplifiers (PAs).

Figure 15.

NASA STRS’ three main hardware functionalities.

In STRS terminology, software includes source code, object code, executables, etc. implemented on a processor. As shown in Figure 16, the STRS software architecture uses three primary interfaces: the STRS APIs, STRS hardware abstraction layer11 (HAL) specification, and the Portable Operating System Interface12 (POSIX®). The STRS APIs provide the interfaces that allow applications to be instantiated and use platform services.

Figure 16.

STRS software architecture layers.

Configurable hardware designs are the items and designs, such as hardware description language (HDL) source, loadable files, data tables, etc., implemented in a configurable hardware device such as a FPGA.

STRS encourages the development of applications that are modular, portable, reconfigurable, and reusable. The STRS software, configurable hardware design, metadata, documentation for STRS applications, STRS devices, and operating environments (OEs) are submitted to NASA STRS Application Repository to allow applications to be reused in the future with appropriate release agreements.

4.2.2 SDR applications in CubeSats

CubeSats13 are increasingly popular spacecraft platforms for mission-oriented experiments that can be accomplished via quick prototyping and launches [10, 11, 12]. This short development timeline is due to the use of commercial-off-the-shelf (COTS) technology that typically has limited resilience to the space environment. Therefore, CubeSat usage has largely been limited to experiments or applications where high availability is not the main objective.

In general, SDR technology will allow for on-orbit flexibility via reconfigurability of data management, protocols, multiple access methods, waveforms, and data protection. SDR processing requirements are inherently scaled to the application. The availability of modular, high-performance sequential and parallel processors that are resilient to radiation upsets allows the tailoring of hardware architectures to the application and to the CubeSat platform. This is especially suitable for missions that require the flexibility to support multiple TT&C and mission data from multiple satellites and ground stations [13, 14, 15].

Given the provided mission flexibility, implementing an SDR on a CubeSat could significantly increase the required processing capacity and thus the size, weight, power and cost (SWAP-C) of the SDR implementation. Consequently, most current CubeSat SDR design and implementation are still customized depending on the mission requirements. In [16], some of the current COTS SDR hardware and software platforms such as GomSpace, Ettus Research USRP, EPIQ Solutions, Lime Microsystems, FunCube, and RTL SDR are described and categorized in decreasing cost and mass to illustrate the heterogeneous nature of SDR in CubeSat applications. Also described are a number of space and ground segment systems built to be (or have been) launched using these COTS SDRs or components thereof. What would be needed is a standard for CubeSat SDR similar to NASA STRS to ensure that hardware and software reuse can be incorporated into future CubeSat developments.

4.2.3 SDR applications in emitter location from space

A pioneering commercial application of SDR in space is the HawkEye 360 (HE360) system [17] that was launched on 3 December 2018. HE360 system consists of three identical spacecrafts and their primary payload is a SDR with custom RF front-end along with VHF Ku-band antennas. This Pathfinder mission14 was to enable onboard reception and geolocation of different types of terrestrial RF signals using signal processing technique to combine received data from all three payloads15.

One commercial application of this mission is the detection and geolocation of a maritime vessel’s automatic identification system (AIS), which broadcasts the locations generated by GPS-enabled receiver. The locations generated by AIS can be disabled or spoofed, therefore not reliable. Another application would be to allow regulators, telecommunications companies, and broadcasters to globally monitor spectrum usage and identify areas of interference. The system can also be used to help large area search and rescue operations by quickly locating activated emergency beacons.

The SDR developed for the Pathfinder payload consists of an embedded processor system and three baseband processors. The baseband processor was built around the Analog Devices 9361 (AD9361) System on Chip (SoC) product, which is a highly integrated RF transceiver that combines high-speed ADCs and DACs, RF amplifiers, filtering, switching plus more. The HE360 payload supported up to three receiver channels (one AD9361 per channel) that can be simultaneously processed on separate frequencies. In addition, the signal processing subsystem takes advantage of open-source software and firmware code to allow system development to proceed without knowing the final space hardware. GNURadio16 was selected for being a free and open-source toolkit for SDR and widely used in small space projects for ground software processing.

4.2.4 Radiation hardening and its current status on SDR hardware

In space, most semiconductor electronic components are susceptible to radiation damage, thus radiation-hardened (or rad-hard) components are required and normally developed based on their COTS equivalents with variations in design and manufacturing17 to reduce the susceptibility to radiation. Consequently, rad-hard components tend to lag behind most recent COTS developments. Depending on mission requirements, rad-hard products are typically selected and tested using popular metrics such as total ionizing dose18 (TID), and single event effects19 (SEEs).

Per US DoD MIL-PRF-38535 J standard [18], an ideal integrated circuit for space applications is the qualified manufacturing line20 (QML) Class V with radiation hardness assurance21 (RHA) level identified in the part specification. From the perspective of payload designer and developer, only Class V is space quality and should be the main factor for selecting SDR hardware components.

The FPGA is perhaps the most important component of an SDR and has a long history for manufactured QML class V parts where rad-hard Xilinx and Actel (now Microsemi) FPGAs were studied [19]. Currently, Xilinx is the major player for space-qualified QML level V products used in actual payloads with many more devices under development. The rad-hard DSP products also follow the QML process, with Texas Instrument (TI) currently taking the lead for in-flight payloads with many offerings in space-qualified RF components in addition to DSP. Similarly, space-qualified GPP follows the same QML path as FPGA and DSP, and the current on-flight rad-hard GPPs based on the following architecture are [20].

  • RISC PowerPC: RAD750, RAD5500.

  • RISC MIPS: RH-32, Mongoose-V, KOMDIV-32.

  • Motorola 68,000 Series: Coldfire M5208

  • ARM Microcontroller: Vorago VA10820

Advertisement

5. Summary and conclusions

In the first section of this chapter, an overview of the satellite bus and payload subsystems are presented for command and data handling subsystem (C&DHS); communications subsystem (CS); electrical power subsystem (EPS); propulsion subsystem (PS); thermal control subsystem (TCS); attitude control subsystem (ACS) also known as guidance, navigation and control (GNC) subsystem; and structures and mechanics subsystem (S&MS). A significant portion is spent on describing the C&DHS and CS with much details on how they are related to other satellite subsystems for continuous operation.

There are distinctive functional separations between the satellite bus and payload that are discussed at a high level with some examples given; however, there are currently no existing standard on their interfaces due to legacy satellite design and development. Examples were given for mission-specific sensing and communications payloads, showing that pretty much all mission payloads are very customized in design in legacy systems.

The second section of this chapter covers software defined radio (SDR) as a new technology with an overview and how SDR is being applied to satellite design and development in both space and ground segments. There has been a NASA standard for SDR that has been used for traditional and large satellites and shown to have some advantages over non-SDR approach.

However, recent rapid developments of Small Satellites (SmallSats), which CubeSat is a subset of, have resulted in an explosion of SDR applications to build Pathfinder missions that can lead to successful follow-on projects. There remains to be a standard to be defined for SDR for this CubeSat application. Regardless, SDR is providing a path forward to a common framework that may enable a more generic building block for a future concept called Software Defined Satellite that will change missions based on a software upload.

Since SDR is becoming an important part of a satellite, radiation hardening of the relevant SDR components is described in some detail. The area is evolving slowly despite fast changing technology due to the additional design and manufacturing steps taken to ensure minimum effects of radiation on microelectronics. The selection of the appropriate rad-hard FPGA, DSP, and GPP components should be an important factor in design trade-offs when SDR is being considered for future missions.

Advertisement

Acknowledgments

The first author, Dr. Hung H. Nguyen, would like to express bountiful appreciation for his wife, Thuy Le Nguyen, for her constant support during this effort.

References

  1. 1. Pelton J, Madry S, Camacho-Lara S, editors. Handbook of Satellite Applications. Vol. 1. Springer; 2013. DOI: 10.1007/978-1-4419-7671-0
  2. 2. Griffin M, French J. Space Vehicle Design, Second Edition, AIAA Education Series; 2004. Available from: https://arc.aiaa.org/doi/book/10.2514/4.862403
  3. 3. Eger G III. Orion’s Command and Data Handling Architecture, AIAA Space 2008 Conference & Exposition; 2008
  4. 4. Yra P, Genna M, McMahon S, Kerns K, Tiede R, Laird M, et al. Next-Generation Spacecraft Command & Data Handling System Based on the RAD750 Processor, 28th AIAA ICSSC-2010; 2010
  5. 5. Kobayashi M et al. NASA’s high-rate Ka-band downlink system for the NISAR mission. Acta Astronautica. 2019;159:358-361. DOI: 10.1016/j.actaastro.2019.03.069
  6. 6. Grayver E. Implementing Software Defined Radio. Springer; 2013. DOI: 10.1007/978-1-4419-9332-8_12
  7. 7. Reed J. Software Radio: A Modern Approach to Radio Engineering. Prentice Hall; 2002. DOI: 10.1109/MS.2003.1207473
  8. 8. Akeela R, Dezfouli B. Software defined radios: Architecture, state-of-the-art, challenges. Computer Communications. September 2018;128. DOI: 10.1016/j.comcom.2018.07.012
  9. 9. Space Telecommunications Radio System (STRS) Architecture Standard, NASA Technical Standard NASA-STD-4009A. Approved: 2018-03-14 Superseding NASA-STD-4009 (Baseline)
  10. 10. Quintana-Diaz G, Birkeland R. Software-Defined-Radios in Satellite Communications, ESA 4S Symposium, Sorrento, Italy, May 2018
  11. 11. Alvarez J, Rice M, Samson R, Koets A. Increasing the Capability of CubeSat-based Software-Defined Radio Applications, 2016 IEEE Aerospace Conference, 5-12 March 2016
  12. 12. Maheshwarappa M, Bowyer M, Bridges C. Software Defined Radio (SDR) Architecture to Support Multi-Satellite Communications, 2015 IEEE Aerospace Conference, 7-14 March 2015
  13. 13. Asundi S, Fitz-Coy N. Design of Command, Data and Telemetry Handling System for a Distributed Computing Architecture CubeSat, IEEEAC Paper #2181, 2013
  14. 14. Joul S, Lightsey G, Horton S, Anandayuvaraj G. A reusable command and data handling system for university cubesat missions. In: IEEE Aerospace Conference; 2014. DOI: 10.1109/AERO.2014.683636
  15. 15. Stott D, Burek R, Eiseneich P, Kroutil J, Schartz P, Sweitzer G. The MSX command and data handling system. John Hopkins APL Technical Digest. 1996;17(2):143-152
  16. 16. Hentschel T, Henker M, Fettweis G. The Digital Front-End of Software Terminals. Dredsen University of Technology; 1999. DOI: 10.1109/98.788214
  17. 17. Sarda K, Roth N, Zee R, CaJacob D, Orr N. Making the Invisible Visible: Precision RF-Emitter Geolocation from Space by the HawkEye 360 Pathfinder Mission, 32nd Annual AIAA/USU Conference on Small Satellites, August 2018
  18. 18. MIL-PRF-38535J. Performance Specification: Integrated Circuits (Microcircuits) Manufacturing, General Specification for (28 December 2010), US DoD
  19. 19. Roosta R. A Comparison of Radiation-Hard and Radiation-Tolerant FPGAs for Space Applications, Jet Propulsion Laboratory, California Institute of Technology, NASA Electronic Parts and Packaging Program. 30 December 2004
  20. 20. Radiation hardening [Internet]. 2020. Available from: https://en.wikipedia.org/wiki/Radiation_hardening [Accessed: 11 May 2020]

Notes

  • Mission type has different meaning depending on context. For example, U.S. military satellite has three basic mission types: imaging/sensing; communications; positioning, navigation and timing (PNT) missions. For NASA space exploration, they are near-earth and deep-space missions.
  • There are three main types of satellite orbits: low earth orbit (LEO) of 2000 km in altitude or less; geostationary (GEO) with altitude around 35,786 km; and medium earth orbit (MEO) with altitude between LEO and GEO.
  • In this context, sounding means sending a radio signal and interpreting the results from the returned signals. Examples are radar and ranging signals.
  • SpaceWire is a spacecraft communication network based in part on the IEEE 1355 standard of communications. It is coordinated by the European Space Agency (ESA) in collaboration with international space agencies including NASA, JAXA, and RKA
  • A CCD is an integrated circuit etched onto a silicon surface to form light-sensitive elements represented by what are called pixels. Photons incident on this surface generate a charge that can be read by electronics as a voltage and turned into a digital copy of the light patterns falling on the device.
  • A cognitive radio (CR) is a radio that can be programmed and configured dynamically to use the best wireless channels in its vicinity to avoid user interference and congestion.
  • Application-specific integrated circuit (ASIC) is designed for specific purpose.
  • Field Programmable Gate Array (FPGA) is an integrated circuit designed to be configured by a designer after manufacturing thus much more general purpose.
  • The Joint Tactical Radio System (JTRS) aims to replace existing radios in the U.S. military with a single SDR to enable new frequencies and waveforms added via software or firmware upload.
  • In a HID, the hardware architecture requirements are written so that the hardware provider defines the functional modules of the system and publishes the functions and interfaces for each module and for the entire STRS platform [Wikipedia].
  • Hardware abstraction layer (HAL) is a layer of programming that allows a computer operating system to interact with a hardware device at a general or abstract level rather than at a detailed hardware level [Wikipedia].
  • The Portable Operating System Interface (POSIX) is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems. POSIX defines the application programming interface (API) for software compatibility with variants of Unix and other operating systems [Wikipedia].
  • CubeSats are a class of Small Satellites (SmallSats) weighing between 1 kg and 10 kgs that use standard size and form factor of 1 U (one unit) of 10 cm x 10 cm x 10 cm. A standard 3 U CubeSat (10 cm x 10 cm x 34 cm, 5 and 6 kg) has been demonstrated to support real mission, and larger CubeSats (6 U, 12 U, and 24 U) are developed.
  • A Pathfinder mission is usually a demonstration to prove that a system can successfully achieve a specific objective before a full mission can deploy.
  • By comparing time-of-arrival (TOA) and frequency-of-arrival (FOA) measurements between pairs of receivers, the position of a signal can be computed.
  • GNU is a recursive acronym for “GNUs Not Unix!” chosen because GNU’s design is Unix-like but differs from Unix by being free software and containing no Unix code.
  • Design trade-offs choosing more better radiation tolerance integrated circuit technology, low-power Schottky vs. Emitter Couple Logic (ECL) vs. bipolar over CMOS. Rad-hard chips are often manufactured on insulating substrates (silicon on insulator, silicon on sapphire, silicon carbide, gallium nitride) instead of the usual semiconductor wafers. Shielding the package against radioactivity to reduce exposure of the bare device.
  • TID causes slow gradual degradation of the device’s performance and is measured in rads.
  • SEEs are caused by a single energy particle and can be (a) non-destructive Single Event Upset (SEU) causing transient pulses in logic or support circuitry or as bitflips in memory cells or registers, (b) potentially destructive Single Event Latch-up (SEL) that may be cleared by a power reset, and (c) destructive Single Event Burnout (SEB) or Single Event Gate Rupture (SEGR), which is irreversible.
  • For QML microcircuits, the manufacturer is required to develop a program plan that meets or exceeds the performance detailed in these appendices of MIL-PRF-38535 J standard.
  • RHA is quantified in terms of the radiation level in Total Ionizing Dose or TID.

Written By

Hung H. Nguyen and Peter S. Nguyen

Submitted: 16 December 2019 Reviewed: 25 May 2020 Published: 06 July 2020