If you wish to contribute or participate in the discussions about articles you are invited to contact the Editor

Receiver Operations

From Navipedia
Jump to navigation Jump to search


ReceiversReceivers
Title Receiver Operations
Edited by GMV
Level Intermediate
Year of Publication 2011
Logo GMV.png

In the first years of GNSS, when only GPS was available for public use, a receiver was not expected to perform as the navigation devices we see today. In fact, a first-generation GPS receiver could be designed to only process 4 or 5 signals at any given time, and it was deemed suitable for positioning applications. Today, with the increased availability and potential of different GNSS signals and constellations, any receiver is expected to support at least 10 or 12 channels up to hundreds, resulting in a solution with improved performance. However, at their core - and despite the many differences in target applications or implementation philosophy - most receivers still share common control and processing flow management properties, resulting in common operations[1] performed. The following sections describe these common operation modes in which a receiver functions.

Overview

One thing most GNSS receivers have in common is how they operate in terms of processing chain, from reception of signals to solution outputs. Although their types, architectures, and applications may vary, the operations (illustrated in Figure 1) apply transversely.

Figure 1: GNSS receiver operations diagram.

After start-up procedures (e.g. loading necessary data, initializations and resource allocations), the antenna and the front-end blocks start providing digitized data continuously to the signal processing channels, also referred to as baseband processing.

Channel Level

A typical GNSS receiver controls independent channels that are assigned to a specific signal from a specific satellite. Each channel can be in two modes: acquisition or tracking. In acquisition mode, each channel conducts a rough 2D search (code delay and Doppler frequency) of the signal in order to assess whether the signal is present or not. The channel remains in acquisition mode until a signal is detected and a first estimate of the code delay and Doppler frequency is computed. At that point, the channel goes into tracking mode where the estimates of the code delay and the Doppler frequency are continuously refined and the navigation message is decoded.

In tracking mode, the channel monitors the quality of the tracking results in order to assess if the signal is present and is being correctly tracked. If the lock detection indicators fall below a threshold, the signal is considered lost and the channel goes back to acquisition mode and re-starts the whole process. The signal can be lost due to several factors such as shadowing of the satellite, cycle slips on the signal, or simply due to noisy initial estimates provided by the acquisition mode.

Receiver Level

At receiver level, the outputs of the channels (measurements and navigation message) are processed into usable solutions. Depending on the application, a GNSS receiver may need measurements from a minimum of three satellites (e.g. for 2D positioning), four satellites (e.g. for 3D positioning) or more satellites (e.g. for liability critical applications). Therefore at global level, if the receiver has enough measurements to provide application data it outputs a solution, otherwise it remains in idle mode. Some receivers might cope with instantaneous lack of measurements by extrapolating from previous measurements or even using information from external sources to support this extrapolation. An example is the possibility to use measurements from an Inertial Measurement Unit (IMU) in order to continue estimating positioning, even in degraded mode. Furthermore, the receiver may also use measurements from a satellite with bad quality indicators just to provide a solution, even if degraded, e.g. in case availability is more important than accuracy for its specific application. This is often the case for receivers that provide 2D solutions when only measurements from three satellites are available, e.g. in car applications where it is reasonable to assume that the user positioning can be map matched to a given road and therefore availability is the key performance factor.

Advanced Operations

On top of the basic operations at channel and receiver level, the overall receiver can further benefit from information either collected from past operations or recently decoded. For example, the receiver can use the information conveyed in the navigation message of a given satellite – e.g. almanacs from other satellites – in order to estimate which satellites are visible and therefore assign channels to those satellites that have a higher probability to be in view. Following these principles, acquisition is often sub-categorized in: cold, warm and hot start mode.

  • In cold start, the receiver has no prior information about its own position or which satellites are in view. As a consequence, each channel has to perform extensive search of all possible signals / satellites over all possible code delay / Doppler frequency pairs. It is only when (at least) one full navigation message is decoded that the receiver can infer the remaining satellites in view (through almanac information), and may redirect the other channels to follow them.
  • In warm start, the receiver has access to rough initial position (e.g. last position before powering down the receiver), and to almanacs relatively up to date (e.g. via external sources or stored at power down). With this information, the receiver is able to predict which satellites are most likely to be in view, and estimate their rough code delay and Doppler frequency, hence being able to narrow down the acquisition search space.
  • In hot start, the receiver has access not only to its rough initial position, but also to the ephemerides of the satellites, hence greatly reducing the acquisition search space, improving the time to acquire and therefore the final Time To First Fix (TTFF).

Related articles

References

  1. ^ Borre, K. et al, "A Software-Defined GPS and Galileo Receiver - A Single-Frequency Approach", Birkhäuser, chapter 5.