Previous development testbeds have assumed that the developer was physically present in front of the hardware being used. No provision for remote operation of basic functions (power on/off or reset) was made, because the developer/operator was sitting in front of the hardware, and could just push the button manually. In this innovation, a completely remotely accessible testbed has been created, with all diagnostic equipment and tools set up for remote access, and using standardized interfaces so that failed equipment can be quickly replaced. In this testbed, over 95% of the operating hours were used for testing without the developer being physically present.
An important design consideration was that all of the instruments and interfaces used stable, long-lived industry standards, such as Ethernet, USB, and GPIB (general purpose interface bus). There are no “plug-in” cards for the two PCs, so there are no problems with finding replacement computers with matching interfaces, device drivers, and installation. The only thing unique to the two PCs is the locally developed software, which is not specific to computer or operating system version. If a device (including one of the computers) were to fail or become unavailable (e.g., a test instrument needed to be recalibrated), replacing it is a straightforward process with a standard, off-the-shelf device.
This strategy has paid off several times over the developmental effort. It made it very easy to construct a “portable” version of the testbed to take to a remote site to test the flight model radio: the two PCs were rented laptops, and copies of the required interface boxes were rented or borrowed. Everything was plugged together, the software was loaded, and a few hours later, testing could commence. Compared to the traditional approach of a rack full of customized interface drawers and customized PCs, it was much simpler and less expensive, as well as immediately responsive to changing project needs.
In fact, the experience of creating an ad hoc test capability at a remote site has resulted in some minor changes to the overall design: for example, rather than individual serial ports, the system now uses USB to serial adapters, all plugged into a USB hub, so there is a single USB connection to the Linux PC. Likewise, in the laptop configuration, the private internal network is implemented with USBEther net adapters, because most laptops come with only one Ethernet interface.
This work was done by James P. Lux, Minh Lang, Kenneth J. Peters, and Gregory H. Taylor of Caltech for NASA’s Jet Propulsion Laboratory. NPO-48013
This Brief includes a Technical Support Package (TSP).
Remotely Accessible Testbed for Software Defined Radio Development
(reference NPO-48013) is currently available for download from the TSP library.
Don't have an account?
Overview
The document outlines the Remotely Accessible Development Testbed for Software Defined Radio (SDR) developed by the Jet Propulsion Laboratory (JPL) under NASA's CoNNeCT Project. This testbed is designed to facilitate the development and testing of the STRS Operating Environment and Test Waveforms for SDR, emphasizing remote operation to minimize the need for physical presence by developers. Over 95% of the testbed's operating hours are conducted remotely, showcasing its efficiency and accessibility.
Key components of the testbed include a Linux host computer, which serves as the primary controller, running essential software and scripts. The system is flexible regarding the Linux distribution used, with CentOS and Ubuntu being examples of operating systems that can be employed. Remote access is facilitated through secure utilities like SSH and SFTP.
The testbed incorporates various hardware interfaces and instruments that adhere to stable, long-lived industry standards such as Ethernet, USB, and GPIB. This design choice eliminates common issues associated with proprietary hardware, allowing for straightforward replacement of components. The testbed's architecture supports a portable version, enabling testing at remote sites with minimal setup time.
Among the notable hardware components are serial ports for console and debugging, a MIL-STD-1553 test interface provided by a Ballard OmniBusBox (OBB), and a SpaceWire interface using a Star-Dundee SpaceWire-USB device. The OBB serves multiple roles, including Bus Controller and Bus Monitor, while the SpaceWire interface allows for high-rate data transfer and telemetry.
The document also mentions the limited utility of a webcam initially included in the testbed setup, which was primarily used for monitoring the hardware's LED status. However, software solutions have since replaced this need, providing more convenient access to status signals.
Overall, the testbed represents a significant advancement in the development of software-defined radio technologies, emphasizing remote accessibility, standardization of components, and ease of use. This innovative approach not only streamlines the development process but also enhances the adaptability of the testbed to meet evolving project requirements. The document serves as a technical support package, providing insights into the testbed's capabilities and its contributions to aerospace technology development.
