CoNNeCT's approach for the development of three Software Defined Radios for space application

Abstract

National Aeronautics and Space Administration (NASA) is developing an on-orbit, adaptable, Software Defined Radios (SDR)/Space Telecommunications Radio System (STRS)-based testbed facility to conduct a suite of experiments to advance technologies, reduce risk, and enable future mission capabilities. The flight system, referred to as the “SCAN Testbed” will be launched on an HTV-3 no earlier than May of 2012 and will operate on an external pallet on the truss of the International Space Station (ISS) for up to five years. The Communications, Navigation, and Networking reConfigurable Testbed (CoNNeCT) Project, developing the SCAN Testbed, will provide NASA, industry, other Government agencies, and academic partners the opportunity to develop and field communications, navigation, and networking applications in the laboratory and space environment based on reconfigurable, software defined radio platforms and the Space Telecommunications Radio System (STRS) Architecture. Three flight qualified SDRs platforms were developed, each with verified waveforms that are compatible with NASA's Tracking and Data Relay Satellite System (TDRSS). The waveforms and the Operating Environment are compliant with NASA's software defined radio standard architecture, STRS. Each of the three flight model (FM) SDRs has a corresponding breadboard and engineering model (EM) with lower fidelity than the corresponding flight unit. Procuring, developing, and testing SDRs differs from the traditional hardware-based radio approach. Methods to develop hardware platforms need to be tailored to accommodate a “software” application that provides functions traditionally performed in hardware. To accommodate upgrades, the platform must be specified with assumptions for broader application but still be testable and not exceed Size, Weight, and Power (SWaP) expectations. Ideally, the applications (waveforms) operating on the platform should be specified separately to accommodate portability to other platforms and support multiple entities developing the platform from the application. To support future flight upgrades to the flight SDRs, development and verification platforms are necessary in addition to the flight system. This paper provides details on the approach used to procure and develop the SDR systems for CoNNeCT and provide suggestions for similar developments. Unique development approaches for each SDR were used which provides a rare opportunity to compare approaches and provide recommendations for future space missions considering the use of an SDR. Three case studies were examined. In two cases, the SDR vendor (General Dynamics and Harris) was the integrated platform and waveform provider. In these cases, the platform and waveform requirements were considered together by the vendor using high level analysis to support the division of the requirements. In the Harris SDR case, the platform and waveform specification was then integrated into a single document. This case study was for a first generation platform, which offers significant processing and reconfigurablility, but is not optimized for SWaP. This provides a test bed platform for many investigations of future capabilities, but requires additional SWaP than optimized flight radios. In the GD case, the specifications were provided separately. The GD SDR leverages existing platforms with minor changes to the Radio Frequency (RF) portions. The most significant change to the CoNNeCT GD SDR from previous platforms was the addition of a reconfigurable processor. The capability tests the next generation SDR, but offers limited capacity and reconfigurability. In the case of the JPL SDR, the platform was developed by JPL and Cincinnati Electronics. Goddard Space Flight Center (GSFC) provided a waveform that was developed on a ground-based development platform, and Glenn Research Center (GRC) ported the waveform to the flight platform and performed the integrated test and acceptance of the subsystem. This last case also leverages an existing platform development, and offers more capacity for reconfigurability than the second case.