GNSS Receivers process the Signals In Space (SIS) transmitted by the satellites, being the user interface to any Global Navigation Satellite System (GNSS). Even though the information provided by a generic GNSS receiver can be used by a wide range of applications, most of them rely on the receiver’s navigation solution – i.e. receiver computed Position, Velocity and Time (PVT).
GNSS receivers determine the user position, velocity, and precise time (PVT) by processing the signals broadcasted by satellites. Because the satellites are always in motion, the receiver has to continuously acquire and track the signals from the satellites in view, in order to compute an uninterrupted solution, as desired in most applications. Any navigation solution provided by a GNSS receiver is based on the computation of its distance to a set of satellites, by means of extracting the propagation time of the incoming signals travelling through space at the speed of light, according to the satellite and receiver local clocks. This time difference is transformed into a fake range, the “pseudorange”, by multiplying it by the speed of the light in the vacuum,
R = c x dt
The pseudorange might be seen as a very rough estimate of the true range between satellite and user, and has to be corrected to account for a number of phenomena before it can be interpreted as a precise measurement of the true distance.
Finding and tracking satellites
Most of the Global Navigation Satellite Systems use Code Division Multiple Access (CDMA) techniques to multiplex several satellite signals onto the same frequency. The basic concept behind the CDMA schemes is that each satellite is assigned with a Pseudo-Random Noise (PRN) code that modulates the transmitted signal. The use of these PRN codes spreads the signal over the spectrum, making it look like noise. Furthermore, the PRN codes have properties such that their autocorrelation function is at a maximum when they are completely aligned. GNSS receivers have prior knowledge of each satellite’s PRN code (e.g. through the relevant SIS ICD), and correlate the incoming signals with local code replicas, to determine if a given satellite is visible or not.
In their most common architecture, GNSS receivers assign a dedicated channel to each signal being tracked and, for the case of multi-frequency receivers, each signal from each satellite can be processed independently. In order to ensure tracking of the signals in each processing channel, receivers are continuously estimating and correcting two parameters:
- The code delay: quantifies the misalignment between the local PRN code replica and the incoming signal.
- The carrier phase (or its instantaneous value, the Doppler frequency): reflects the relative motion between the satellite and the user.
In order to determine these parameters, the receiver puts in place (code and carrier) tracking loops that form the core of the signal processing and continuously track the incoming satellite signal, in order to generate the code and carrier phase measurements. Each estimate of the code delay and the carrier phase is used to regenerate the local PRN code replica, which is then correlated again with the incoming signal. The result of this operation is then re-assessed at the receiver to re-estimate these parameters, in a continuous loop. After synchronization with the incoming signals and demodulation of the navigation message, the receiver is able to determine pseudoranges to each satellite, and to compute a navigation solution.
Receivers continuosly evolve
Back in the 1970s, receivers were large analog equipments built for the military domain. Nowadays, GNSS receivers have been widely expanded to miniaturized platforms, chipsets, microprocessors, Integrated Chips (IC), DSP, FPGA, handheld devices, including integration in most mobile phones. In fact, GNSS receivers run in a wide variety of platforms, and the choice results from a trade-off of parameters such as receiver performance, cost, power consumption and autonomy.
Furthermore, the increasing capabilities of microprocessors have enabled the emergence of software receivers with performances comparable to hardware implemented receivers, providing the flexibility required for some user applications.
Following future trends, with the emergence of multiple satellite navigation systems (both regional and global), multi-constellation receivers are increasingly available. This has been encouraged at system design level, by working towards interoperability and compatibility. From the receiver perspective, multi-constellation brings a key added value to solution availability, especially in urban environments.