Editor’s Note: This is the second article in a three-part series about software defined radios in GPS/GNSS simulators.

Part 1: About GPS and various techniques that are used to advance signal technology, satellite systems and signals, architecture and modernization efforts

Part 2: GPS simulators, software defined radio architecture and its integration into simulators

Part 3: Testing using SDRs and GPS signal examples

The application of satellite navigation in everyday products has increased exponentially, with integrated GNSS receivers being used in navigation, ground mapping and surveying, construction, transportation, geospatial information systems (GIS), machine control, port automation, precision agriculture, timing and surface mining, and many more. Although the GNSS based system can be verified with actual GNSS signals in the field using “Live Sky” testing, a GNSS simulator provides an effective and efficient means to test embedded GNSS products. The simulator emulates and imitates the GNSS satellite constellations, atmospheric conditions, including both Ionosphere and Troposphere errors, satellite clock and atmospheric errors, vehicle and satellite motion, GNSS signal characteristics, and overall different levels of a hostile RF environment. It is imperative to test for these obstructions and parameters in order to mitigate them for a variety of applications.

The received GPS/GNSS signal can be very weak due to a variety of factors, including the signal being obstructed by buildings and objects, or jamming or degradation by unintentional RF interference or intentional jammers. The RF interference environment is likely to increase due to a proliferation of telecommunications devices (mobile subscriber services and commercial/military spectrum crowding and intentional jamming) which may adversely affect the performance, continuity, and integrity of receivers operating in different applications. Introducing these variables into a real-world testing schedule may be impractical and will have a large impact on the amount of time it takes to bring the product to market. A GPS/GNSS simulator can very faithfully simulate the RF jamming, spoofing, and a multipath environment, thus effectively utilizing the product testing regime to make the GNSS-based system more robust and reliable.

The GNSS receiver or system under test, once connected to a simulator, will be subjected to the same conditions as in a field environment. The simulated signal will be consistent and the unit being tested will be subjected to a repetitive and uniform GNSS signal, comparable to live test conditions. This simulation enables testing of all current and future signals, while allowing for the incorporation of important edge or borderline cases that are impossible to predict in the real world.

There are many types of GNSS simulators available, with RF signal record/replay simulators providing a cost effective way for developers to record GNSS scenarios in the field and replay them in a controlled environment. High-end full constellation simulators can simulate the GPS L1/L2/L5, Galileo E1/E5/E6, GLONASS L1/L2 and BeiDou B1I/B2I/B3 frequency bands, as well as the augmentation systems. They are fully capable of multi-constellation, multi-frequency simulations for a wide range of test scenarios used in research and development of GNSS enabled devices.

Many of the commercially available GNSS simulators can simulate dual frequency IRNSS, GPS, GLONASS, BEIDOU, GALILEO along with SBAS and DGNSS augmentation systems. The system can simulate all the available GNSS satellites as per user selection, introduce signal anomalies like satellite orbit and clock errors, environmental models for ionosphere and troposphere, different antenna models, receiver clock errors along with multipath, and signal interference effects. The simulator usually supports RS-232, RS-485 interfaces for DGNSS corrections, and the Ethernet interface for the diagnostic port. It can select single/multiple channels of GNSS constellations and is capable of multipath simulation. The simulator has navigation data modeling and supports error modeling for receiver autonomous integrity monitoring (RAIM) tests, waypoint navigation, and all types of vehicle simulation via motion commands or user motion/NMEA files.

As mentioned earlier a newly developed GPS/GNSS product will require extensive testing and for developers of GNSS/GPS-enabled devices, having the ability to reliably test a device in the same way each time will reduce the development time, increase product reliability and be more cost effective. Reliable acquisition of a GNSS signal, consistent tracking and device performance in changing environments are all the key factors of GPS device testing.

A GPS simulator provides the developer a number of advantages. The most obvious is that of convenience and being able to replay raw RF satellite signals directly into GPS equipment in the confines of the lab or office, without having to venture outdoors, clearly makes testing easier.

Legacy GPS/GNSS simulators had dedicated resources to simulate the GPS constellation and signals and utilized expensive and high-end vector signal generators to emulate these signals. This resulted in stand-alone and sometimes multiple cabinets full of rack mount test equipment to simulate scenarios to test GPS products. With the advancements of SDRs, this can be reduced to a 3U system.

SDRs use of field programmable gate arrays (FPGAs) coupled together with high performance and flexible radios, it is becoming possible to run different simulation programs on commercial off the shelf (COTS) machines connected to SDRs. The advances in high frequency analog-to-digital convertors (ADC), digital-to-analog convertors (DAC) and digitization techniques have facilitated the rise of software defined radio (SDR) based simulators, which feature an internal processor and software-defined architecture that allows for the simulation of hundreds of satellites or different RF environments using a highly flexible and scalable architecture.

A software defined radio (SDR) comprises a radio frontend (RFE) that digitizes the RF signal with the help of analog-to-digital convertors (ADC) (or DACs for transmit) and multiple independent channels, with a digital backend, which consists of a FPGA with digital signal processing (DSP) capability. In high end SDRs each receive (Rx) or transmit (Tx) channel works independently, allowing for complex multi-input multi-output (MIMO) operations spanning various frequencies that are also synchronized by precision time boards. The system can be configured to function as RF and digital receivers, transmitters, transceivers, pulse generators, waveform generators, and (de)modulators with advanced triggering and radio performance.

SDRs are able to receive and transmit signals over a broad tuning range and can have instantaneous bandwidth of up to 3 GHz with multiple DSP channels within the 3 GHz bandwidth enabling the operation at different frequencies using a single radio chain.

Due to the flexibility, SDRs are very easy to integrate into new and legacy defence and communication systems. They are especially capable of reducing the complexity and amount of hardware-based components necessary in a different systems across radar, GPS/GNSS, spectrum monitoring, and more. This is due to the SDR’s ability to embed various signal-processing algorithms in software, including waveform generation, storage, modulation, encryption, down-conversions, and up-conversion.

SDRs have a reconfigurable RFE which allows for the same platform to be used for different applications, as it can operate on various bands of the radio spectrum. For example, different GPS and GNSS applications operate at L1-band while others can operate at L2, E5, E1, E6, etc.. The overall reduction in complexity allows for savings on space, cost, and reduces the time-to-market and  supply chain issues. Usually SDRs are primarily coded in C++ and Python, with the complexity of code dependent on intended use and integration. GNU Radio is a free software development toolkit which provides signal processing blocks to be used in conjunction with software defined radios and signal-processing systems.

In order to design and develop the GNSS-based products it is imperative to simulate the entire GNSS signal transmission and reception scenario in a detailed format. It comprises two distinct parts:

The typical RFE of a GPS receiver includes an antenna, amplifiers, local oscillator (LO), mixers and an ADC responsible for sampling the down-converted analog signal to digital format suitable for signal processing. The baseband samples are processed using software routines to generate the receiver position information as shown in the Figure 1 below.

Figure 1: Block diagram of a basic SDR GPS Receiver. (Source: Per Vices)

The purpose of the acquisition process is to identify whether a certain satellite is visible or not. If the satellite is visible, the acquisition algorithms determine the coarse values of carrier frequency and code phase of the signal. The legacy GPS receivers employed serial search acquisition on account of the hardware implementation simplicity. Nowadays, more efficient Fast Fourier Transform (FFT)-based acquisition algorithms are used, such as parallel code phase search acquisition, which enable implementation of multiple (> 100) correlators for the multi-frequency and constellation GNSS receiver. The SDR based simulator can facilitate further development of these algorithms by making use of the flexibility afforded by using FPGAs for the DSP.

Control is then handed over to the tracking algorithms (stage 3 in Figure 1), which is used to track the variations in the carrier Doppler and code offset (due to line-of-sight dynamics between the satellite and the receiver), and demodulate the navigation data from the specific satellite. Most commercial receivers employ 2nd order phase lock loop (PLL), however, development of algorithms (third order PLL and/or Kalman filter based) for improved signal tracking performance, especially in low signal-to-noise (SNR) and dynamic conditions, is ongoing. Through the use of SDR based simulators, the development time for testing and validating these new development algorithms can be reduced.

After successful tracking, the navigation and ephemeris data is decoded. Ephemeris is a set of data/table that provides the positions of celestial objects (stars, planets, satellites) on given dates in past and future. In order to perform receiver position calculations, you need to calculate the satellite positions, which are based on the satellite orbit information present in the ephemeris data and refer to the Keplerian orbit elements, which describes the satellite orbit plane position relative to another body. The receiver position can be calculated after computing the first set of pseudoranges. The most commonly used method for GPS position calculations is based on the least squares method. A SDR can be used to perform all above-mentioned functions using software routines and the necessary parameters can be updated or fine-tuned to obtain an optimum solution.

In an SDR the antenna, RFE and ADC/DAC are the only parts still implemented in hardware. These components output a bit stream that contains digitized navigation data, which are then fed as input. From this point on, almost every operation is performed through software implementation, some of which may come out to be critical for their quite demanding real-time requirements. If the code architecture is well and conveniently designed, such a flexible, modular and open receiver can be used not only to fix and compute position, velocity and time (PVT), but also to assess the GNSS performances. It also allows for the development and testing of new algorithms for navigation signal reception, including testing future signals for prediction of future performance and characteristics. Requiring minimal, if any, hardware reconfiguration is the main strength of SDR receivers. This significantly reduces costs for receiver development, maintenance, and enhancement.

Since traditional hardware receivers already implement PVT algorithms in software, the main difference between a hardware and a software receiver consists in the acquisition, tracking and data demodulation steps. In a traditional receiver, these operations are performed by specific hardware, properly designed and optimized to implement them, and would require a redesign or replacement in order to use new signals. SDRs are optimized for complex algorithms through the integration of high-performance FPGAs and DSPs, which allow for faster data acquisition, demodulation, and processing of GNSS tracking and navigation data.

For more Embedded, subscribe to Embedded’s weekly email newsletter.

You must Sign in or Register to post a comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed.