GNSS Software Defined Radio: Real Receiver or Just a Tool for Experts? - Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design

GNSS Software Defined Radio: Real Receiver or Just a Tool for Experts?

In recent years, a new trend in designing GNSS receivers has emerged that implements digitization closer to the receiver antenna front-end to create a system that works at increasingly higher frequencies and wider bandwidth. This development draws on an earlier software receiver (SR) or software defined radio (SDR) approach originating from signal processing technologies used in military applications.

In recent years, a new trend in designing GNSS receivers has emerged that implements digitization closer to the receiver antenna front-end to create a system that works at increasingly higher frequencies and wider bandwidth. This development draws on an earlier software receiver (SR) or software defined radio (SDR) approach originating from signal processing technologies used in military applications.

Today, GNSS software receivers have achieved a level of considerable technological maturity and use, particularly in signal analysis and receiver engineering, and appear poised for much wider adoption in commercial equipment and applications. This column expands on an abbreviated introduction of this topic in our discussion of platforms for future GNSS receivers in a previous “Working Papers” (March, 2006).

In this column, we will briefly describe the history of SR development, introduce the categories of GNSS SR design and implementations to date, provide an overview of commercial SR products and applications, and the future outlook for GNSS SRs.

History of GNSS Software Receivers

In the early 1990s the U.S. military services were facing several communications-related challenges. These included such matters as ensuring communication with current allies and a global support structure, denying interception of radio messages by hostile elements, taking advantage of the rapid technology changes, and controlling costs of R&D and purchasing.

At that time, military radio designs were based on hardware technology optimized for a single, specific field application and typically assumed a 30-year development life span, that is, the time from product release to the use of its next-generation replacement in new designs. During the 1990s, however, commercial applications started driving technology development so that the effective lifetime of a commercial component design fell to less than two years.

As a result of this change in the equipment design and development environment, a U.S. Department of Defense (DoD) multi-phase joint service project named Speakeasy was undertaken with the objective of proving the concept of a programmable waveform, multiband, multimode radio. (See the paper by R. J. Lackey and D. W. Upmal in the “Additional Resources” section near the end of this article.) The Speakeasy project demonstrated an approach that underlies most software receivers: the analog to digital converter (ADC) is placed as near as possible to the antenna front-end, and all baseband functions that receive digitized intermediate frequency (IF) data input are processed in a programmable microprocessor using software techniques rather than hardware elements, such as correlators.

The flexibility of the programmable implementation of all baseband functions allows rapid change and modifications not possible in analog implementations.

This flexibility is an advantage in the military environment where communication at different ranges and to different command levels may require different radio frequency (RF) bands, modulation types, bandwidths, and spreading/despreading and baseband algorithms.

SDR is the underlying technology behind the Joint Tactical Radio System (JTRS) initiative to develop software programmable radios that enable seamless and real-time communication for the U.S. military services with coalition forces and allies. The functionality and expandability of the JTRS is built upon an open framework called the Software Communication Architecture.

(For the rest of this story, please download the complete article using the PDF link above)

IGM_e-news_subscribe