RFQ Attachment A - Specifications-Requirements - 140G0120Q0155.pdf

DCN LSDS-1987

Version 1.0

Department of the Interior U.S. Geological Survey

Programmable Demodulator Specifications and Requirements

Version 1.0

May 2020

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 1 of 41

- ii - DCN LSDS-1987

Programmable Demodulator Specifications and Requirements

May 2020

EROS

Sioux Falls, South Dakota

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 2 of 41

- iii - DCN LSDS-1987

Executive Summary

This Programmable Demodulator Specifications and Requirements document provides the technical requirements and specifications for the NMB019 (FBMS 40488143) next-generation demod procurement.

The requirements are formally managed in DOORS, which comprise the most current, managed version, and should be used as the latest version. DOORS is referenced for USGS internal tracking only.

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 3 of 41

- iv - DCN LSDS-1987

Document History

Document Number Document Version Publication Date Change Number

LSDS-1987 1.0 May 2020 N/A

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 4 of 41

- v - DCN LSDS-1987

Contents

Executive Summary ..................................................................................................... iii

Document History ........................................................................................................ iv

Contents ......................................................................................................................... v

List of Tables ................................................................................................................ vi

Section 1 Introduction

1.1 Background

1.2 Purpose and Scope

1.3 Document Organization

1.4 Terminology

1.5 Applicable Document

Section 2 Landsat Ground System Element Overview

2.1 Data Processing and Archive System (DPAS)

2.1.1 Inventory System

2.1.2 Ingest System (IS)

2.1.3 Subsetter System

2.1.4 Image Assessment System (IAS)

2.1.5 Landsat Product Generation System (LPGS)

2.1.6 User Portal (UP) System

2.1.7 International Cooperator Web Portal (ICWP)

2.1.8 Mission Management Office (MMO) Database System (MDS)

2.1.9 Archive and Access (A&A)

2.2 Ground Network Element (GNE)

2.2.1 Landsat Ground Network (LGN)

2.2.2 Command and Telemetry Processor (CTP)

2.2.3 Data Collection and Routing System (DCRS)

2.3 Landsat Multi-Satellite Operations Center (LMOC)

2.3.1 Telemetry & Command (T&C)

2.3.2 Data Management (DMS)

2.3.3 Trending & Analysis (T&A)

2.3.4 Flight Dynamics (FDS)

2.3.5 Mission Planning (MPS)

2.3.6 Alerts and Notifications (ANS)

2.3.7 Analytical Modeler (AM)

2.3.8 Infrastructure (Inf)

Section 3 Operations Concept/Usage Scenarios

3.1 Landsat 7 Operations

3.2 Landsat 8 Operations

3.3 Landsat 9 Ground System Development

3.4 Landsat 9 Spacecraft/Observatory Test Support

3.5 Landsat 9 Commissioning

3.6 Landsat 9 Operations

3.7 Landsat Next Notional Development

3.8 Landsat Next Notional Spacecraft/Observatory Test Support

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 5 of 41

- vi - DCN LSDS-1987

3.9 Landsat Next Notional Operations

3.10 Landsat Realtime Operations

Section 4 Technical Requirements and Specifications

4.1 Technical Requirements and Specifications

4.2 Reference

List of Tables

Table 4-1. Technical Requirements and Specifications

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 6 of 41

- 1 - DCN LSDS-1987

Section 1 Introduction

The Landsat mission is a joint mission formulated, implemented, and operated by the National Aeronautics and Space Administration (NASA) and the Department of the Interior (DOI) U.S. Geological Survey (USGS). Landsat is a remote-sensing satellite mission providing coverage of the Earth’s land surfaces. The Landsat series of satellites continue the 40+ years of global data collection and distribution.

1.1 Background

The goal of Landsat is to continue the collection, archival, and distribution of multispectral imagery affording global, synoptic, and repetitive coverage of the Earth’s land surfaces at a scale where natural and human-induced changes can be detected, differentiated, characterized, and monitored over time. The Landsat programmatic goals are stated in the United States Code, Title 15 Chapter 82 “Land Remote Sensing Policy” (derived from the Land Remote Sensing Policy Act of 1992). This policy requires that the Landsat Project provide data into the future that are sufficiently consistent with previous Landsat data to allow the detection and quantitative characterization of changes in or on the surface of the Earth. The highly successful Landsat series of missions have provided satellite coverage of the Earth’s continental surfaces since 1972. The data from these missions constitute the longest continuous record of Earth’s surface as seen from space.

1.2 Purpose and Scope

The primary purpose of this document is definition of the demod technical specifications and requirements as a portion of the package for the NMB019 (FBMS 40488143) next-generation demod procurement.

1.3 Document Organization

This document contains the following sections:

• Section 1 provides an introduction

• Section 2 provides an overview of the Landsat ground system elements and subsystems for background information and context

• Error! Reference source not found. provides a summary of usage scenarios (operations concept) for the demod in various development and operational cases

• Section 4 lists the requirements and specifications

1.4 Terminology

A Requirement is a specification of a function, capability, or constraint with which the system design must be compliant, verifiable, and have a demonstrated achievement during the mission.

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 7 of 41

- 2 - DCN LSDS-1987

A Shall statement designates a mandatory requirement that must be verified through an accepted process. Any deviations from these requirements require Configuration Control Board (CCB) approval.

1.5 Applicable Document

The following is an applicable document for these requirements and specifications (the relevant text has been extracted and included in the rationale statements):

LSDS-1877 LGN Requirements Document -v3.0 2018_05_15

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 8 of 41

- 3 - DCN LSDS-1987

Section 2 Landsat Ground System Element Overview

2.1 Data Processing and Archive System (DPAS)

DPAS provides functionality to archive, ingest, and process mission data to produce interval files and subset interval files into Worldwide Reference System-2 (WRS-2) scenes, and to generate Level 0, Level 1, and Level 2 products for distribution to the public. DPAS also maintains an inventory of metadata and browse for each scene product to support search and download of metadata, products, and browse data.

DPAS archives mission data and browse in accordance with the Landsat Sentinel Archive Access (LSAA) Archive Policy. DPAS leverages the enterprise capability of LSAA and the LSAA Archive Policy to ensure data are permanently preserved by maintaining a copy of the data at the National Archive and Records Administration (NARA) facility, in an offline archive and a nearline archive.

A key role throughout the Landsat missions is to ensure the accurate spectral, radiometric, spatial, and geometric characterization and calibration of the Landsat instruments and their data products. DPAS includes the functionality used for the characterization, calibration, and validation of the Landsat data and products. A set of calibration parameters and auxiliary datasets are maintained and used to create Level 1 and Level 2 products that are sufficiently consistent with previous Landsat missions, allowing detection and quantitative characterization of changes in the Earth’s land surface.

The primary science objective of the Landsat mission is to generate a global high-quality observational record of land image data in continuity with the Landsat satellite series. The basic premise of the Long-Term Acquisition Plan (LTAP) is to acquire all defined, sunlit, collection sites per the LTAP Collection Request (LCR) table of path/row-based information, including all land, coastal/littoral regions, islands, reefs, atolls, and shallow water ecosystems where the sensors provide useful measurements.

In addition, a variety of night (non-sunlit) targets are acquired, and a collection request process is available for science campaigns. LTAP addresses methods to select how candidate scenes are rejected when optimizing the schedule to meet resource constraints. Due to the distribution of candidate scenes and the annual change in solar illumination, portions of time occur where the candidates may exceed the system capacity.

USGS maintains agreements with several foreign governments, referred to as International Cooperators (ICs), which have the ability to receive Landsat data from the Observatory real-time downlink stream. DPAS provides an IC Web Portal (ICWP) where ICs can retrieve orbital parameters, downlink schedules, and calibration parameters used for tracking the Observatory, downlinking mission data, and processing. As part of the agreements with USGS, ICs provide DPAS metadata related to the collected data, and provide mission data, Level 1, and Level 2 data annually for validation purposes;

USGS makes mission data available as part of a bilateral exchange program. DPAS ICWP also provides functionality for the exchange of these data.

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 9 of 41

- 4 - DCN LSDS-1987

For the general user community, DPAS also provides a portal to all Landsat information, called the Landsat Missions Website (LMWS). The LMWS provides access to project descriptions, sensor updates, news items, product information, historical information, and Frequently Asked Questions (FAQs). It provides the science community with the ability to view or download calibration data, calibration notices, and science-related studies. The LMWS also provides quick access to Really Simple Syndication (RSS) feeds, data access tools, sample imagery, and links to numerous Landsat-related sites and resources.

2.1.1 Inventory System

The Inventory System performs two key database functions for the DPAS: a master Landsat Mission Database (LMD) and the Searchable Inventory (SI) Database (SID).

The LMD component maintains the master copy of mission, interval, and scene metadata. The LMD is designed to support long-term archiving, data tracking, and data integrity. The LMD is isolated for security and is a protected resource.

The SIDs are database tables optimized for searching scene, mission, and engineering data. The SID components contain a subset of the LMD information and are highly optimized to support fast product search and ordering. Three SIDs are available:

• User SID, the primary searchable inventory

• Mission SID, used by approved users with signed agreements with the USGS, such as ICs

• Engineering SID, used by Calibration/Validation (Cal/Val) for analysis, calibration, anomaly resolution, and algorithm development

2.1.2 Ingest System (IS)

The primary work of the IS is to format mission data retrieved by the Ground Network Element (GNE) into Level 0 Reformatted Archive (L0Ra) data. With this formatting, selected data types are analyzed for impulse noise and saturated pixels, data gaps are filled, duplicate lines are eliminated, ancillary data with suspicious time stamps are flagged, interval and scene metadata are generated, and processing metrics are collected.

• Inputs:

o Mission data intervals o Calibration parameters for alignment and scene framing o Response Linearization Look-Up Table (RLUT) used in histogram statistics and bias parameter generation

• Processing:

o Perform initial quality checks (e.g., Cyclic Redundancy Check (CRC), line and frame headers) o Flag suspect time stamps in ancillary data o Create interval and scene metadata o Format the data for efficient processing

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 10 of 41

- 5 - DCN LSDS-1987

o Extract and/or calculate sensor, spacecraft, and image statistics

• Outputs:

o L0Ra intervals and metadata o Standardized characterization data to the Image Assessment System

(IAS) database o Bias parameters for product generation

2.1.3 Subsetter System

The Subsetter System extracts Level 0 Reformatted Product (L0Rp) data from L0Ra data. The system monitors for new requests and initiates the Operational Land Imager (OLI) / Thermal Infrared Sensor (TIRS) Subsetter for each request. These requests are then subsetted out of L0Ra and into L0Rp files. L0Rp data (or untouched L0Ra data if the request is for a complete interval) are staged to the L0Rp Cache and the requesting system is notified of processing completion (L0Rp status) and the location of the data.

2.1.4 Image Assessment System (IAS)

The IAS is responsible for the offline assessment of image quality to ensure compliance with the radiometric and geometric requirements of the spacecraft and the sensors throughout the life of their respective missions. Operational activities occur at the USGS Earth Resources Observation and Science (EROS) Center; less frequent assessments and calibration certifications occur at the Landsat Project Science Office, which is located at the Goddard Space Flight Center (GSFC) in Greenbelt, Maryland.

The IAS characterizes radiometric and geometric artifacts through a series of algorithms. The outputs of the algorithms and their statistics are captured in a relational database for trending, analysis, modeling, and calibration. The IAS processes up to 75 scenes per day for image quality assessment, radiometric and geometric calibrations and characterizations, and artifact correction.

The IAS also stores and provides various auxiliary datasets needed for image processing. These auxiliary datasets include the Calibration Parameter File (CPF), Bias Parameter File (BPF), Ground Control Point (GCP), Digital Elevation Model (DEM) data, and RLUT.

2.1.5 Landsat Product Generation System (LPGS)

The LPGS generates standard Level 1 data products, which include a 16-bit Quality Band (QB) and an angle coefficient file for distribution. Along with the Level 1 product, the LPGS also generates a Full Resolution Browse (FRB) and an 8-bit QB. The LPGS uses the same algorithms to generate Level 1 products that the IAS uses within its Level 1 processor. This method allows the LPGS to provide identically calculated characterization data to the IAS for trending and analysis. The LPGS provides metadata to Inventory for product tracking and to support search and order capabilities.

2.1.6 User Portal (UP) System

The UP has been functionally decomposed into the following components: Collection Request Interface (CRI), User Services, and Exchange Cache. The web-based CRI

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 11 of 41

- 6 - DCN LSDS-1987

allows the submission of LCRs, Special Collection Requests (SCRs), and Calibration Collection Requests (CalCRs). Authorized users may submit an SCR to the Data Acquisition Manager (DAM) for approval, and then send the request to the Landsat Multi-Satellite Operations Center (LMOC) for scheduling consideration. LCRs and CalCRs are submitted to the LMOC without formal DAM approval in the UP. The LMOC returns the scheduled/unscheduled status of each request through schedule files written to the Exchange Cache for use by the web-based CRI. Clients external to DPAS can request Landsat metadata through web services that the Services component provides.

Services components serve both internal and external requests. The Exchange Cache component is a temporary storage area for pickup and delivery of IC validation and exchange data. The Exchange Cache component provides scheduling artifacts to the ICs and maintains a repository of Station Performance Reports for operational monitoring of Landsat Ground Network (LGN) and IC performance. The Exchange Cache is also used to store new Landsat 9 Data Manager requested operational files.

2.1.7 International Cooperator Web Portal (ICWP)

The International Partnership Task Plan, which falls under the Land Satellites Data System (LSDS) Program, manages the ICWP. The ICWP uses EROS Registration Service (ERS)-provided Single Sign-On (SSO) authentication, which provides station-specific point-of-entry for important information and datasets relevant to the Landsat IC community. The ICWP provides access to the latest USGS software updates and documentation, scheduling information, sample datasets, IC meetings (proceedings and initiatives), and other information to support the Landsat IC Network. The ICWP also gives ICs the ability to submit station profile information and communication messages, and to upload metadata, mission data, and Level 1 files for data exchange and data validation purposes.

2.1.8 Mission Management Office (MMO) Database System (MDS)

To support Landsat Project operations, the MDS provides mission status information that the Landsat Project and MMO requires for managing and directing Project activities. The MDS collects metrics and metadata from the DPAS, GNE, and Enterprise systems to create various types of reports needed to monitor the Landsat mission.

Fundamental to MDS processing is Extract, Transform, and Load (ETL), whereby data from different system databases are obtained and organized for analysis. The MDS Transfer Service (MTS) component executes ETL processing of the Scene to Interval File Mapping Table (SIFMT), Scene Transmit Schedule (STS), inventory metadata, demographics, order information, and metrics from the various systems. These data are stored in a centralized data warehouse to support mission reporting needs.

Once the metrics and metadata are loaded into the data warehouse, users can generate standard reports such as volume, throughput, latency metrics, data quality metrics, customer demographics, downlink reconciliation reports, etc., from a web-based Metrics Reports Graphical User Interface (GUI) (MRG). These reports can also be exported into a file to support presentations, meetings, or sharing with others. The enterprise (IC) Portal also uses the STS information from the MDS data warehouse to

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 12 of 41

- 7 - DCN LSDS-1987

determine an IC Capture Success Rate (CSR) for each of the ICs that downlink Landsat data.

The Mission Manager uses the standard reports to track mission activities, processing performance, and to direct Landsat activities, such as:

• Identifying bottlenecks in the systems as candidates for performance improvements

• Watching volume trends to direct purchasing of additional disk at the appropriate time

• Determining what types of organizations use Landsat data and for what purpose, to understand the Landsat user community needs

In addition to standard reporting, the Mission Manager has direct access to the MDS data warehouse in order to create ad hoc reports.

The Data Manager uses discrepancy reports to identify the differences between what was scheduled and what was not received or processed through DPAS. Once the Data Manager has identified the reason for the discrepancies, the discrepancies can be inserted into the MDS data warehouse via the MRG to reconcile the differences.

The MDS Operations staff uses a GUI to monitor and control the ETL process, data warehouse, and metrics reporting.

2.1.9 Archive and Access (A&A)

The storage, archive, registration, and access capabilities that support the Landsat mission are maintained under EROS enterprise components. The LSAA Project at EROS provides the resources necessary to store and archive Landsat data and maintain external interfaces that allow end users to access Landsat data.

2.1.9.1 Data Archival and Storage

EROS provides an enterprise solution for long-term storage and High Availability (HA) of Landsat data files. This solution includes an NARA-compliant, off-site archive for mission-critical files (such as mission data), supporting files that must be preserved (such as prelaunch data and milestone test results), and files deemed critical to disaster recovery (such as browse). Data that do not require off-site archival, including routine backups, test data, and distributable products (such as Level 1 bundles), are stored with in-house redundancy. LSAA provides the space, security, management, technology updates, and usage reporting, but DPAS maintains database inventories of its data in the archival and storage system.

2.1.9.2 Imagery and Metadata Access and Distribution (EarthExplorer (EE))

EE is an enterprise solution that EROS provides for end users to discover and access Landsat imagery and image metadata. Registered users can preview, filter, select, and download standard Level 1 products, browse, and metadata. Specific users, such as the

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 13 of 41

- 8 - DCN LSDS-1987

Calibration/Validation Team (CVT) and ICs, may also access Level 0 products and mission data.

The web-based or application interface helps users identify scenes and facilitates the download of scene data one at a time, in small batches, or in bulk. Interfaces comply with security and visual identity requirements, provide “Help,” and accept user feedback.

A&A also tracks and reports data access. The A&A interfaces use the enterprise user registration solution, enterprise tracking and reporting solution, DPAS databases, and the enterprise data storage solution.

2.1.9.3 Tracking, Routing, and Metrics (TRAM)

EROS provides an enterprise solution to support submission and routing of data processing requests. Internal systems use defined interfaces to submit processing requests in small or large batches. The order routing system honors priority designations as it interfaces with DPAS Systems that generate products as requested by internal systems or end users. The system also provides order status and reports on order throughput.

EROS proved an enterprise solution for centralized tracking and reporting of internal and end user ordering, data access, and distribution. Regular reports are broken out and categorized as appropriate. The LSAA Team provides ad hoc reports as needed.

2.1.9.4 EROS Registration System (ERS)

EROS provides an enterprise solution for users to securely register and log in to the system. The registration system secures and encrypts Personally Identifiable Information (PII) in accordance with applicable guidelines. The system captures user demographics, which may be used in reporting. Account managers, such as Customer Service staff, may assign users specific roles, enabling access to non-standard data or distribution methods. Interfaces that provide access to EROS data, such as the enterprise data access and distribution interfaces, securely exchange user authentication tokens with the registration system. The registration system also authenticates in-house systems for the order routing system as needed.

2.1.9.5 Landsat Missions Website (LMWS)

The LSAA Project manages the LMWS; Landsat and Science manage the content. The LMWS provides access to project descriptions, sensor updates, news items, product information, historical information, and FAQs. It provides the science community with the ability to view or download calibration data, calibration notices, and science-related studies. The LMWS also provides quick access to RSS feeds, data access tools, sample imagery, the latest USGS software updates and documentation, and links to numerous Landsat-related sites and resources.

2.2 Ground Network Element (GNE)

The primary function of the GNE is to provide Radio Frequency (RF) communications between the spacecraft and the ground system. GNE provides the S-Band interface between the LMOC and spacecraft for Command (CMD) and Telemetry (TLM), 140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 14 of 41

- 9 - DCN LSDS-1987

Tracking, and Control (TT&C) communications. GNE also provides the X-Band interface to receive, collect, and transfer science mission data intervals from the spacecraft to the DPAS for archive, processing, and Stored State of Health (SSoH) telemetry from the spacecraft to the LMOC. GNE includes three subsystems: Landsat Ground Network (LGN), Command and Telemetry Processor (CTP), and Data Collection and Routing System (DCRS).

2.2.1 Landsat Ground Network (LGN)

The LGN is made up of multiple stations that provide S-Band command uplink, S-Band telemetry downlink, X-Band science mission data, and SSoH telemetry downlink capabilities with the spacecraft. The LGN is responsible for station control, scheduling, and maintenance activities.

2.2.2 Command and Telemetry Processor (CTP)

The CTP provides the S-Band command and telemetry processing interface between the spacecraft and the LMOC. It is responsible for streaming S-Band telemetry received from the spacecraft to the LMOC and transmitting commands sent by the LMOC to the spacecraft. The same CTP units are used at each LGN station.

2.2.3 Data Collection and Routing System (DCRS)

The DCRS has multiple functions. The DCRS resides at each LGN station and houses an LGN cache. The DCRS is responsible for storing all data successfully captured by each Ground Station and generating a GNE Post-Pass Report (GPR) detailing the science mission data files received for each pass. The LGS DCRS has additional functionality. It receives science mission data, SSoH telemetry data, and the GPRs from the DCRS at each remote LGN station. The files transferred from those instances, as well as Landsat Ground Station’s (LGS) local LGN cache, are transferred to and stored in the LGS DCRS combined cache, which is where interval assembly takes place per the Scene-to-Interval-to-File Mapping Table (SIFMT). The LGS DCRS is also responsible for routing GPRs and SSoH telemetry data to the LMOC after every Landsat contact and for transferring full intervals to DPAS for processing and archiving.

After successful transfer to the permanent archive, the science mission data files remain in a rolling cache for a period of time.

2.3 Landsat Multi-Satellite Operations Center (LMOC)

The LMOC handles management of image and calibration acquisitions, commands the generation for all Observatory activities, and monitors Observatory health, safety, and performance. The LMOC comprises the facility and systems that include the capabilities identified in the following sections.

2.3.1 Telemetry & Command (T&C)

Galaxy is used to provide archive and acquisition of real-time S-Band telemetry from the various antenna complexes, generate and encrypt commands for uplink, manage the Solid State Recorder (SSR), and execute time-based automation tasks.

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 15 of 41

- 10 - DCN LSDS-1987

2.3.2 Data Management (DMS)

Mercury manages file distribution and event-based automation within the LMOC. A central agent administers configurations and provides web-portal services while various remote agents perform actual automation work.

2.3.3 Trending & Analysis (T&A)

Stars ingests S-Band real-time, S-Band SSoH, and X-Band SSoH data; Stars also generates statistical data. It produces both automated and user interface outputs in plot and various machine-readable formats.

2.3.4 Flight Dynamics (FDS)

FreeFlyer, FreeFlyer Meridian, and Multi-Mission Three-Axis Stabilized Spacecraft (MTASS) are used to perform orbit determination and propagation, orbit maintenance, attitude prediction, attitude determination, and Onboard Computer (OBC) sanity checks.

2.3.5 Mission Planning (MPS)

Collection Planning and Analysis Workstation (CPAW) and Systems Toolkit (STK) Scheduler process inputs from flight dynamics, various collection requests from DPAS, and other sources to generate the contact schedules and activity plans for the spacecraft and ground system.

2.3.6 Alerts and Notifications (ANS)

Graylog and What’s Up Gold process log messages in order to generate alert notifications to the Flight Operations Team (FOT) Engineers.

2.3.7 Analytical Modeler (AM)

The Joint Activity Simulation for Observatories and Networks (JASON) models mission behavior in a multi-satellite system, including expected spacecraft and ground system activities and realistic failure scenarios.

2.3.8 Infrastructure (Inf)

An amalgamation of Commercial Off-the-Shelf (COTS) and open-source software, which provides services related to network, compute, disk, authentication, remote access, security, backups, video distribution, and other tools.

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 16 of 41

- 11 - DCN LSDS-1987

Section 3 Operations Concept/Usage Scenarios

3.1 Landsat 7 Operations

The L7 S/C provides up to three concurrent D/Ls on separate frequencies directed by gimbaled antennas to one, two, or three stations. Each D/L is 150 MBits/sec with filtering of the mainlobe to 110 MHz bandwidth (less than the 150 MHz bandwidth defined by the first ± clock nulls). The modulation is AQPSK (I and Q datastreams use different clock sources and require separate independent clock recovery). Typically, a station receives two D/Ls using adjacent frequency channels (i.e. – XLOW + XMED or XMED + XHIGH) containing RT + PB or PB +PB data. Separate demods are used for each D/L with a block D/C and IF tuning to receive XLOW, XMED or XHIGH. The demod captures a raw CADU bitstream file which is copied to a L0 processor at the end of the pass.

3.2 Landsat 8 Operations

Data from L8 consists of four VCs containing RT and PB mission data wrapped in CFDP files and one of two VCs containing SSOH X-Band TLM data (file). Rate-7/8 [NASA] LDPC forward error-correction is used. The data rate of 384 MBits/sec is thus expanded to a symbol rate of 441 MSymbols/sec by LDPC. The demod receives the D/L from L8 and performs demodulation, bit synchronization, LDPC forward error-correction, and VC processing to extract packet datastreams for the four VCs containing mission data files. These VCs are sent to CFDP processors for realtime checksum verification and mission data file extraction (for files the pass checksum verification).

The mission data files are renamed to append date/time information and ID information for the reception (station) location so they are uniquely-named, and copied to a shared directory on the demod that is also mounted to a data handling system to be transferred for L0/L1 processing.

The L8 D/L is heavily filtered to meet spectral constraints with the symbol modulation of 441 MSymbols/sec filtered to fit within the allocated 375 MHz D/L bandwidth.

Asymmetrical filtering is used to ensure DSN band protection at the upper end of the D/L band, so the adaptive filtering in the demod is essential to meeting the 10-12 operational BER requirement. The D/L uses a TWT amplifier with back-off to the linear range of operation.

SSOH X-Band TLM data in either of the other two VCs is copied to a separate file as a separate raw CADU file (X-Band CCSDS formatting removed) that is copied to a shared directory on the demod so the data handling system can forward the SSOH data file to LMOC after the file is closed at the end of the pass. Mission data files and SSOH X- Band TLM data files are cleaned up periodically by the external data handling system.

Files that fail checksum verification (NAK) are placed into a separate directory for possible analysis at a later time, and these files are manually cleaned up. CFDP file error state is displayed on the demod GUI and is also reported via the remote status and control interface.

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 17 of 41

- 12 - DCN LSDS-1987

The demod logs all CFDP files received (ACKs and NAKs), with the CFDP error code recorded in the log. The logs can be set up, so they are generated by date or by date window, or by log file size. Log files are used in some cases to extract lists of successful CFDP file reception to close the control loop for mission data management and guaranteed file delivery.

3.3 Landsat 9 Ground System Development

The demod will be used to simulate nominal L9 operations for ground system testing, simulating the reception and processing of a nominal D/L (see item 6 below).

The demod is also used as a test modulator to generate a simulated D/L signal (at IF) for testing or a PN signal for bit error-rate testing. The test modulator function either plays back a raw CADU file or generates a simulated D/L data stream from input mission data files and SSOH data that are CFDP-wrapped and placed into VCs in a multiplexed datastream that is modulated. The multiplexed datastream can also be recorded as a raw CADU file to generate a test file that can be used for multiple applications instead being generated on-the-fly each time.

3.4 Landsat 9 Spacecraft/Observatory Test Support

The demods are used to support multiple activities for S/C test support. For RF compatibility testing, the demods are used to measure I/Q imbalance and bit-error rate of the S/C, and the acquisition threshold of the demods is also measured using the S/C D/L. As part of the BER measurements, the demod is used to measure Eb/No, Es/No, and input power, as well as LDPC performance (statistics).

During S/C data flows, the demod is used to monitor realtime VC processing, CFDP processing as files are received by the demod, and concurrent raw CADU file capture and CFDP processing. Mission data files from CFDP files are extracted in realtime as they are received and checksum-verified and sent to a L0/L1 processor (via a shared network filemount) for further analysis.

The CCSDS and CFDP processing sections of the demod are used to process raw CADU files captured at other locations to extract mission data files for further analysis.

The input is a raw CADU file on external media (i.e. – USB drive or network location) or a file that has been copied to a local directory for processing.

A copy of the demod application S/W (performs the CCSDS and CFDP processing not done in FPGA demodulation/FEC H/W) is used for offline processing of raw CADU data to extract mission data files for testing and analysis. A copy of the demod S/W is also used to implement a ground system interface to the S/C simulator, where the data stream that would have been modulated and downlinked is routed via a network connection (1000baseT) to the demod S/W for CCSDS and CFDP processing to simulate nominal operations (this is effectively receiving a raw CADU datastream over a network connection and processing it like the datastream coming from internal demod H/W components).

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 18 of 41

- 13 - DCN LSDS-1987

3.5 Landsat 9 Commissioning

L9 commissioning will use many of the same functions as S/C testing, including realtime processing during passes, concurrent CFDP processing and raw CADU file capture, and BER measurement using the S/C D/L

3.6 Landsat 9 Operations

L9 operations is nearly identical to L8 ops, with the exception that different file locations are used for mission data and SSOH files, and the file-naming of mission data files is slightly different, RRRRRSSS (where RRRRR is the five digit rootfile ID and SSS is the three digit subfile number, the decimal point used in L8 being implied in order to provide additional mission data file address space while still retaining the same length mission data file name).

The L9 D/L is nearly identical to L8, with heavy asymmetric filtering requiring the use of adaptive filtering to meet the operational 10-12 BER requirement. L9 uses a TWT with less power, but still at a back-off to operation before the 1 dB compression point.

3.7 Landsat Next Notional Development

Landsat next development functions will be similar to those listed above for L9 development, where the demod will be used to test/simulate nominal mission ops and generate a simulated D/L signal. It is our expectation that ground development will be ahead of S/C development and we will need to internally generate simulated S/C test data and D/L signals working from the design and ICD covering the D/L signal and data formatting. The demod will also need to support on-orbit BER testing using a PN D/L from the S/C during commissioning.

3.8 Landsat Next Notional Spacecraft/Observatory Test Support

It is our expectation that an HGS-like capability will be implemented for Landsat next S/C development support, with the ability to receive and CFDP-process data in realtime as it is sent from the S/C, as well as make a raw CADU copy of the data. The RF and signal characterization tests (see 3.4 above) will also be performed using the demod.

The demod (S/W) will need to implement an interface to the S/C simulator, though it has not yet been defined if this is a H/W interface (i.e. – serial or parallel data/clock connection) or network (1000baseT).

3.9 Landsat Next Notional Operations

It is our expectation that Landsat next operations will be similar to L8/9 (see 3.2 above), just at higher data rates and possibly more VCs. For planning purposes, we’ll assume that we have twice the number of VCs to concurrently process in the D/L, four SSOH TLM and eight mission data/CFDP.

The data rates have yet to be defined, but we will use the NEN/NIKA rates as a surrogate for now. The demod would receive data at up to 1.75 GBits/sec using SQPSK/UQPSK or 8-PSK modulation. LDPC forward error-correction (NASA variant)

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 19 of 41

- 14 - DCN LSDS-1987

will be assumed since it is spectrally efficient (2 GSymbols/sec), and CFDP will be used in the same way L8 and L9 works for file-based data transmission and management.

3.10 Landsat Realtime Operations

The demod receives the D/L from L8 or L9 and performs demodulation, bit synchronization, LDPC forward error-correction, and VC processing to extract a raw CADU datastream. VC63 fill data is discarded from the datastream in the VC processor, and some or all of the VCs containing data may be selected to be streamed over a network (1000baseT) connection to an external L0 processing system. A copy of the raw CADU datastream containing all the data VCs is also written to an internal file on the demod as a backup or later processing.

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 20 of 41

- 15 - DCN LSDS-1987

Section 4 Technical Requirements and Specifications

4.1 Technical Requirements and Specifications

The table below lists the requirements and specifications for the demod procurement.

Table 4-1. Technical Requirements and Specifications

ID Section Requirement Rationale (as needed)

1.0 Functional Requirements

The demod units shall be fully multi-mission capable with the ability to be programmed or configured to support various missions.

Mission configurations shall be changeable for local and remote users/automation.

Configuration presents need to be selected by automation for pre-pass setup and manually by the ops staff

A local operator shall be able to change to any valid saved configuration while directly interfacing the unit.

Operators need to make changes to the loaded configuration preset via the demod GUI once a preset has been loaded

A remote operator or automation system shall be able to change to any valid saved configuration.

Make changes to the loaded configuration preset via the demod GUI once a preset has been loaded using the automation system remote interface/remote control.

2.0 Input Characteristics

005 All IF inputs shall be 50 Ohm impedance

50 Ohm terminators shall be included on all open ports

Prevents noise for leaking into the unit or RF energy leaking out to cause interference to adjacent equipment.

All IF inputs shall support 600 MHz or greater input bandwidth.

Heritage L8 demod requirements and performance value

The 600 MHz bandwidth shall be presented as ± 300 MHz about the center frequency.

Heritage L8 demod requirements and performance value

The demod shall bandwidth of ± 755 MHz at the 2400 MHz IF center frequency

010 Demod shall provide tuning of the IF input to

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 21 of 41

- 16 - DCN LSDS-1987

ID Section Requirement Rationale (as needed) support frequency offset or multiple channels when a block D/C is used

All IF inputs shall support 0 to -50 dBm input power levels and dynamic range.

Nominal signal level difference between AOS and PCA on a high-elevation pass

At least one input shall support 1200 MHz IF center frequency

At least one input shall support 720 MHz IF center frequency

Unit shall support a 2400 MHz IF input Support for next-generation higher data rate missions

The demod shall have an adjustable frequency sweep rate of at least ± 25 KHz/sec

L9-SC-GND-2846 For wideband telemetry, the ground system receivers operating in the 8 GHz band shall have a maximum frequency sweep rate of at least ± 25 KHz/s

The demod shall be capable of frequency acquisition at ± 300 KHz about the IF frequency

L9-SC-GND-2844 For wideband telemetry, the ground system shall be capable of frequency acquisition at 8.2005 GHz ± 300 KHz

3.0 Modulation and Filtering

The demod units shall support the following demodulation schemes compliant with CCSDS 401.0-B-19 Radio Frequency and Modulation Systems Blue Book:

• BPSK

• QPSK

• UQPSK (Unbalanced, I and Q data streams are different data rates with amplitudes of I and Q phase vectors adjusted to fit inside unit circle)

• 8-PSK (8-ary PSK, phase states are 45° apart)

• SQPSK (Staggered, I and Q data streams are out of phase to minimize transition discontinuities and maintain continuity between phase states)

• OQPSK (Offset-Keyed, I and Q data streams are phased 90° apart)

• AQPSK (Asynchronous, I and Q clocks are

LGN-31861 The LGN shall perform OQPSK demodulation on the X- Band downlink

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 22 of 41

- 17 - DCN LSDS-1987

ID Section Requirement Rationale (as needed) not correlated nor coherent)

• Variable PSK (Order of PSK changes during pass as a function of Eb/No over the duration of pass, controlled by measured Eb/No or operating from a time-based scheme)

The demod units shall provide a matched and/or custom filter that is independent of the data rate or symbol rate.

To meet bandwidth constraints, mainlobe is filtered to less than the bandwidth defined by the data rate (clock nulls) and the matched filter needs to match the actual received signal bandwidth to prevent reception of excess noise from adjacent channels.

Filtering of the mainlobe could be as high as 34%.

LGN-31856 The LGN shall receive the 441 Msps OQPSK modulated LDPC encoded 384 Mbps X-Band downlink filtered to 375 MHz

The matched and/or custom filter shall allow for setting bandwidth independent of the data rate, i.e. - will accommodate a signal that is band-limited to less than the full main lobe in bandwidth (as measure by ± clock null.

Landsat 7 D/L has a 3 dB signal bandwidth of 110 MHz for a 150 MBits/sec D/L rate, and Landsat 8/9 has a 3 dB bandwidth of

373.24 MHz for a 440.832

MSymbol/sec D/L rate

LGN-31856

4.0 Adaptive Filtering

The unit shall provide the capability to apply adaptive equalization to improve data and symbol recovery.

LGN-31862 The LGN shall utilize adaptive baseband equalization for receiving the X-Band downlink

The unit shall provide the capability to manually or automatically set the initial conditions of the adaptive equalizer.

LGN-31862

The unit shall provide the capability to apply adaptive equalization independent of, and in addition to the standard matched or custom data filter.

LGN-31862

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 23 of 41

- 18 - DCN LSDS-1987

ID Section Requirement Rationale (as needed)

The unit shall have the ability to store preset parameters of an adaptive filter for use as a custom filter and/or use in setting initial parameters for an adaptive filter.

LGN-31862

The unit shall report status, to both the manual front panel user interface and the remote status and control interface, indicating when a matched filter has converged.

LGN-31862

The unit shall report an error when the adaptive filter will not converge in a reasonable time period.

LGN-31862

The adaptive filtering shall be capable of implementing a filter with 45 dB or greater of stopband rejection.

LGN-31862

Operation of the adaptive filter shall not interfere with the normal operation of the matched or custom data filter.

LGN-31862

The adaptive filter shall be capable of low-pass, high-pass, bandpass, and band-stop filtering.

LGN-31862

The adaptive filter shall provide the capability to simulate arbitrary filter responses to simulate satellite downlink transmit filtering.

LGN-31862

The adaptive filter shall provide 8 dB or better of performance improvement when converged.

LGN-31862

5.0 Data Capture

The demod shall support a data Rate 1.75 GBits/sec (2 GSymbols/sec with Rate-7/8 LDPC coding) via the 2400 MHz IF frequency

Support for NIKA/NEN missions as backup and projected rates from next-generation higher resolution Landsat sensors with additional spectral coverage

The demod units shall support an input symbol rate of up to 2000 MS/s (Mega Symbols per second) or greater.

Assuming rate-7/8 LDPC FEC at a data rate of 1.75 GBits/sec

The demod units shall support single continuous raw CADU file capture without any embedded framing or headers.

Raw CADU data captured by the demod needs to be portable between multiple systems and a single continuous file without any additional information or embedded markers is the most generic format

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 24 of 41

- 19 - DCN LSDS-1987

ID Section Requirement Rationale (as needed)

LGN-31891 The LGN shall capture block address data from the observatory when requested by the LMOC

The demod shall provide filtering to select virtual channels to be included or excluded for raw CADU capture

Filter VC63 fill data out, depending upon specific needs for data capture

LGN-31885 The LGN X- Band receive system shall capture all S/C stored telemetry downlinked in X- Band LGN-31890 The LGN shall record the state of health telemetry present in the X- Band downlink

The demod shall provide raw CADU capture of data by one or more virtual channels

LGN-31885

LGN-31890

The demod units shall name raw CADU capture files with selectable parameters to include:

• Date Time information defined by user

• Station capture designator (3 digit/letter designator of ground station e.g. LGS)

• Optional text information up to 63 characters (e.g. unit ID, etc.)

LGN-31886 The LGN X- Band VC10/VC14 file recorder shall record all data with unique file names based on the AOS and LOS times

The demod shall store raw CADU capture files in a user-defined location that includes that ability to segregate files by source VC

LGN-31887 The LGN X- Band VC file recorder shall record all VC10/VC14 data into unique directory paths that identify the VC being captured LGN-31888 The LGN X- Band VC file recorder shall provide all recorded files in a directory path that is accessible by the DCRS LGN-31889 The LGN X- Band receive system shall ensure all data recorded for DCRS is input into unique directory paths to identify the receiver from which it was captured

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 25 of 41

- 20 - DCN LSDS-1987

ID Section Requirement Rationale (as needed)

The demod shall simultaneously capture raw CADU data while performing CFDP processing

6.0 CCSDS Processing

The demod units shall support channelization by virtual channel in a single signal from the spacecraft compliant with CCSDS 132.0-B-1 TM Space Data Link Protocol Blue Book.

The demod units shall support all CCSDS virtual channels for a given spacecraft mission up to the limit of 63 simultaneous channels.

VC0-VC62 for data with VC63 fill data

The current missions supported by LGS that require CCSDS channelization are:

The Landsat 8 and 9 will downlink a single carrier with a 384 Mbps data rate which will be presented as a combination of the following:

• VC00 - OLI real time data (main mission data downlink)

• VC05 - TIRS real time data (main TIRS mission data downlink)

• VC08 - Solid state recorder downlink #1

• VC10 - Stored state of health #1 (S-Band TLM stored and downlinked in X-Band)

• VC12 - Solid state recorder downlink #2

• VC14 - Stored state of health #2

The demod shall support use of all 63 VCs (0-

62) simultaneous virtual channel outputs from a single input signal compliant with CCSDS 132.0-B-1

Support for future missions

The demod shall provide configurable virtual channel (VC) processing

LGN-31872 The LGN shall provide configurable virtual channel (VC) processing on the X-Band downlink

The demod units shall support application process identifier (APID) per CCSDS 133.0-B- 1 Space Packet Protocol Blue Book.

The demod units shall support selectable removal and/or addition of Space Packet headers.

7.0 CFDP Processing

The demod units shall support the CCSDS File Delivery Protocol compliant with the CCSDS 727.0-B-4 Blue Book.

LGN-31880 The LGN X- Band CFDP processor shall close the file corresponding to the metadata PDU upon

140G0120Q0155 - RFQ Attachment A - Specifications/Requirements Page 26 of 41

- 21 - DCN LSDS-1987

ID Section Requirement Rationale (as needed) receipt of the EOF PDU LGN-31881 The LGN X- Band CFDP processor shall perform checksum verification of all received CFDP files

The demod units shall support simultaneous CFDP transactions within a single virtual channel.

The demod units shall support simultaneous CFDP data paths from the output of the VC processor and APID processors.

The demod shall perform simultaneous processing of all VCs containing CFDP data

Will concurrently work for as many VCs of CFDP data are present in the D/L.

This applies for as many CFDP processors are configured in the preset, but this could be less than the total number present in the D/L if not all VCs are required to be processed

LGN-31871 The LGN shall perform CFDP processing on each virtual channel (VC) separately for each VC that includes CFDP data LGN-31874 The LGN X- Band CFDP processor shall process a single file transaction…