Text Size
OpNom:
Overview | Description | Applications | Operations | Results | Publications | Imagery
Experiment OverviewThe Space Communications and Navigation Testbed (SCAN Testbed) consists of reconfigurable software defined radios (SDRs) with software based communications and navigation functions that provide ground mission planners the capability to change the functionality of the radio once on-orbit.
The ability to change the operating characteristics of the radio?s software after launch allows missions to change the way a radio communicates with ground controllers, and offers the flexibility to adapt to new science opportunities and increased data return.
Additionally, this flexibility allows teams to recover from anomalies within the science payload or communication system, and potentially reduce development cost and risk by using the same hardware platform for different missions while using software to meet specific mission requirements.
Developer(s)
United States Department of Defense Space Test Program, Johnson Space Center, Houston, TX, United States
Glenn Research Center, Cleveland, OH, United States
Goddard Space Flight Center, Greenbelt, MD, United States
Jet Propulsion Laboratory, California Institute of Technology, Pasadena, CA, United States
National Aeronautics and Space Administration (NASA)
Sponsoring OrganizationTechnology Demonstration Office (TDO)
Research BenefitsInformation Pending
ISS Expedition Duration:May 2012 - September 2014
Expeditions Assigned31/32,33/34,35/36,37/38,39/40
Previous ISS MissionsThis is the first instance of SCAN Testbed operation in microgravity.
NASA's Space Communication and Navigation Office is developing the Space Communications and Navigation Testbed (SCAN Testbed) to investigate the applicability of software defined radios (SDR) to NASA missions. A part of the investigation is an architecture standard for SDRs used in space-based and ground-based platforms to provide commonality among radio developments in an effort to provide enhanced capability and services while reducing mission and programmatic risk by reducing the need for custom, proprietary radio architectures. This radio architecture standard provides value by employing common waveform software interfaces, and methods for instantiation, operation, and testing among different compliant hardware and software products. Such common interfaces within the architecture, mask the underlying hardware through application programming interfaces and other software layers enable independent technology insertion at either the software or hardware layer. This common architecture entitled Space Telecommunications Radio System (STRS) provides the desired software abstraction and flexibility while minimizing developmental and operational resources by tailoring the implementation to functions typically required of NASA radios.
Traditional approaches to radio development have been exemplified by proprietary or custom implementations that only meet a specific set of mission requirements. Presently most requirements can only be satisfied by functions implemented in the hardware (i.e., application-specific integrated circuits (ASIC's)) and thus fixed for a specific mission duration, and historically this was often the only approach, given the available ASIC technology, suitable for space flight. As software defined radios (SDR) begin to infuse deep space, near-Earth, and lunar space applications, a new approach must be considered to best apply the new reprogrammable field programmable gate array (FPGA) technologies for NASA. The advent of software-based radio functionality offers NASA the opportunity to separate the software proliferation and its associated complexities from the underlying and evolving reprogrammable hardware technology by adopting an open architecture standard. Published, well defined interfaces enable different vendors to provide radios that conform to the interface standard, providing commonality among different implementations and enabling interoperability between providers of different hardware and software elements. Standard interfaces provide for software component reuse, and technology insertion through the hardware abstraction. Such a standard also promotes the growth of a large base of domain experts; agency personnel, software and hardware providers, and the user and operations communities, which help reduce the risks of using unique custom architecture implementations.
SCAN Testbed hosts three SDRs based on the STRS Standard. The radios provide different and complimentary capabilities while having the ability to reconfigure their functions based in signal processing hardware (e.g., processors or field programmable gate arrays). The functions performed by the radios include communication with the Tracking and Data Relay Satellite (TDRS) system in both S-Band and Ka-Band, receive Global Positioning Satellite (GPS) signals, and enable proximity communications between the International Space Station (ISS) and approaching vehicles.
The hardware consists of a flight enclosure mounted on a Flight Releaseable Attachment Mechanism (FRAM). There are five main components of the payload: the avionics system, the software defined radios, the radio frequency (RF) subsystem, the antenna pointing system, and heaters. Except for the five externally mounted antennas, most of the subsystems are installed on the inside of the enclosure.
SDRs enable new valuable communications capabilities for space missions. Historically, for a given mission, development and verification concentrates on platform hardware functionality to ensure the hardware performs as designed and that the software operates on functionally equivalent ground systems. The SDR reconfigurable software allows communication functions to be updated during development and in flight for both system infrastructure and flight radios. Reprogrammable radios are able to adapt to changing mission requirements during development through software/firmware changes. This has the benefit of mitigating schedule impacts, including significant savings with respect to hardware changes due to unforeseen issues or requirements scope increases. Adding software or firmware to the SDR after launch could decrease development and delivery time by the mission launching with less than the fully operational software and adding the software after launch.
Another potential benefit is the ability to change functions within the same radio across different mission phases providing the potential to reduce radio hardware and have fewer radios to cover the same number of mission phases. The SDR can also be used to mitigate failures and use all available communication link energy in flight to obtain greater science data return for missions. In addition, waveform application upgrades can be made in flight to adjust to changing conditions.
STRS-compliant software defined functionality enables transceivers to be tailored for specific missions with reusable software. The SCAN Testbed experiment program provides waveforms and software components to the STRS waveform repository and enables future hardware platforms to utilize common reusable software modules in order to reduce development time and costs. The SDR and STRS use for space missions will reduces NASA's dependence on specific suppliers reducing cost risk to NASA programs, savings tax payer dollars.
The STRS architecture developed for space is considered within the SDR community as a viable architecture for ground based platforms with small resources of memory and processing capacity; much like a satellite radio. NASA's support for a common, open architecture aids in the development of open standards for other domains beyond space.
SCAN Testbed requires a frequency assignment between the flight system on ISS and TDRS at S-Band and Ka-Band, as well as a command and control interface to/from the ground to the payload system to configure the radios and antenna systems. A data connection, separate from the ISS, provides a bi-directional connection between the radios and ground stations (e.g., White Sands). Individual SCAN Testbed experiments are conducted using the testbed on a regular basis, within operational constraints. Experiments are expected to be conducted on a weekly or bi-weekly basis, ranging from 60 minutes to several days in durations. In order to point antennas, the SCAN Testbed needs ISS position and attitude information.
Operational ProtocolsSCAN Testbed is an external payload which requires no crew interaction. Commands are sent from the GRC Telescience Support Center (TSC) to configure and operate a radio for an experiment. A typical S-Band or Ka-Band experiment involves sending pseudorandom or network traffic experiment data to or from the on-board radios through the Space Network (SN) program satellites, the Near Earth Network (NEN) or various ground stations and the TSC. For GPS experiments, a radio is specifically configured to receive and process GPS signals. GPS data is collected on-board and sent to ground via telemetry. Various parameters and data quality measures are routinely manipulated and examined in order to determine the efficacy of the test software on the radios.
Briones JC, Handler LM, Johnson SK, Nappier J, Gnepp S, Kacpura TJ, Reinhart RC, Hall CS, Mortensen D. Space Telecommunications Radio System (STRS) Definitions and Acronyms. NASA Technical Memorandum; 2008.
Briones JC, Handler LM, Hall SC, Reinhart RC, Kacpura TJ. Case Study: Using the OMG SWRADIO Profile and SDR Forum Input for NASA's Space Telecommunications Radio System. NASA Technical Memorandum; 2009.
Reinhart RC, Johnson SK, Kacpura TJ, Hall CS, Smith CR, Liebetreu J. Open Architecture Standard for NASA's Software-Defined Space Telecommunications Radio Systems. Proceedings of the IEEE. 2007; 95(10): 1986-1993. DOI: 10.1109/JPROC.2007.905071.
Ground testing and processing of SCAN Testbed hardware (JPL)
Schematic overview showing SCAN Testbed hardware and components (JPL)
External image of ISS showing SCAN Testbed installed on ELC 4 nadir side (NASA)