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

System Design Details: Difference between revisions

From Navipedia
Jump to navigation Jump to search
No edit summary
No edit summary
Line 22: Line 22:
*<b>Antenna</b>: L-band antenna for capturing GNSS signals, with the associated amplification and filtering. It represents the entry point from the space segment to the user segment, and receives the L-band signals to pre-process and feed as an analog electrical signal to the front end (still as a 1.2 - 1.6 GHz range RF signal).
*<b>Antenna</b>: L-band antenna for capturing GNSS signals, with the associated amplification and filtering. It represents the entry point from the space segment to the user segment, and receives the L-band signals to pre-process and feed as an analog electrical signal to the front end (still as a 1.2 - 1.6 GHz range RF signal).


*<b>Front End</b>: The front end section receives the RF inputs from the antenna, and performs down-conversion, filtering / amplification, and sampling (digitizing) of the captured signals. Typically in a superheterodyne<ref>http://en.wikipedia.org/wiki/Superheterodyne_receiver</ref> configuration, the front end converts the analog GNSS signals to digital data streams in an intermediate frequency (IF) spectrum (centered in the MHz range), and finally to a baseband digital signal in-phase (I) and quadrature (Q) components.
*<b>Front End</b>: The front end section receives the RF inputs from the antenna, and performs down-conversion, filtering / amplification, and sampling (digitizing) of the captured signals. Typically in a superheterodyne<ref>[[wikipedia:Superheterodyne receiver]]</ref> configuration, the front end converts the analog GNSS signals to digital data streams in an intermediate frequency (IF) spectrum (centered in the MHz range), and finally to a baseband digital signal in-phase (I) and quadrature (Q) components.


*<b>Baseband processing</b>: All acquisition and tracking [[Digital Signal Processing|signal processing]] tasks are performed in the baseband processing blocks, where the core functions that enable GNSS signal tracking occur, such as correlations, delay/frequency/phase lock loops, filtering, and others. Receivers typically process several channels in parallel, where different signals are tracked, and produce observables like code delay, carrier phase, and Doppler frequency, as measurement data.
*<b>Baseband processing</b>: All acquisition and tracking [[Digital Signal Processing|signal processing]] tasks are performed in the baseband processing blocks, where the core functions that enable GNSS signal tracking occur, such as correlations, delay/frequency/phase lock loops, filtering, and others. Receivers typically process several channels in parallel, where different signals are tracked, and produce observables like code delay, carrier phase, and Doppler frequency, as measurement data.
Line 37: Line 37:
*<b>Single/Multi Frequency/Constellation</b>: An increasing range of GNSS frequencies, bands, modulations and constellations enable a multitude of possibilities in receiver design, from single frequency / single constellation (e.g. the common GPS L1 C/A devices on current PND's or smartphones) to multi-frequency / multi-constellation (e.g. L-band GPS/Galileo/GLONASS capable high-end survey receivers).
*<b>Single/Multi Frequency/Constellation</b>: An increasing range of GNSS frequencies, bands, modulations and constellations enable a multitude of possibilities in receiver design, from single frequency / single constellation (e.g. the common GPS L1 C/A devices on current PND's or smartphones) to multi-frequency / multi-constellation (e.g. L-band GPS/Galileo/GLONASS capable high-end survey receivers).


*<b>Assisting Sources</b>: Several external or assistance information sources can be taken into account at system design, since there is a straightforward impact on resources and solution computation. If the use of augmentation (SBAS) or differential (DGPS) data is envisaged, the receiver must be prepared to interface and use the information provided from such systems. Other external interfaces and aiding sensors can be coupled to a receiver, such as inertial sensors<ref>http://en.wikipedia.org/wiki/Inertial_measurement_unit</ref> (IMU and INS), or even the means to get external aiding information (e.g. accessing the internet through WiFi or GPRS/UMTS).
*<b>Assisting Sources</b>: Several external or assistance information sources can be taken into account at system design, since there is a straightforward impact on resources and solution computation. If the use of augmentation (SBAS) or differential (DGPS) data is envisaged, the receiver must be prepared to interface and use the information provided from such systems. Other external interfaces and aiding sensors can be coupled to a receiver, such as inertial sensors<ref>[[wikipedia:Inertial measurement unit]]</ref> (IMU and INS), or even the means to get external aiding information (e.g. accessing the internet through WiFi or GPRS/UMTS).


*<b>Hardware Platform</b>: On a physical platform point of view, several design considerations are made in terms of the hardware host platform, user interface design, storage capability, power/battery consumption, electromagnetic compatibility, or portability. The underlying platform for a GNSS receiver can be an ASIC, FPGA, DSP, CPU, hardware/software defined, or a combination of these and other technologies. Table 1<ref>Hein, G., Pany, T., Wallner, S., Won, J., <i>"Platforms for a future GNSS receiver - A discussion of ASIC, FPGA, and DSP technologies"</i>, Working Papers, InsideGNSS, March 2006.</ref> below shows an assessment of the advantages and disadvantages of each approach.
*<b>Hardware Platform</b>: On a physical platform point of view, several design considerations are made in terms of the hardware host platform, user interface design, storage capability, power/battery consumption, electromagnetic compatibility, or portability. The underlying platform for a GNSS receiver can be an ASIC, FPGA, DSP, CPU, hardware/software defined, or a combination of these and other technologies. Table 1<ref>Hein, G., Pany, T., Wallner, S., Won, J., <i>"Platforms for a future GNSS receiver - A discussion of ASIC, FPGA, and DSP technologies"</i>, Working Papers, InsideGNSS, March 2006.</ref> below shows an assessment of the advantages and disadvantages of each approach.

Revision as of 13:37, 12 April 2011


ReceiversReceivers
Title System Design Details
Author(s) GMV
Level Medium
Year of Publication 2011
Logo GMV.png


In order to process the L-band signals transmitted from the satellites and compute the navigation solution, a GNSS receiver can be designed to target different applications, markets, and solutions. From single or multi-frequency, single or multi-constellation, to survey or automotive applications, system specification details extend through a broad range of decisions and trade-offs, in order to achieve the best performance desired. The following sections tackle some considerations at a GNSS receiver system design level.

Overview

Most of the current GNSS receiver systems gather (at least) the blocks depicted in Figure 1, although some architecture variations might be present to accommodate different solutions. Besides these blocks, other common receiver components are the power unit (e.g. batteries) or the enclosure (e.g. for ruggedization). All such components and blocks are carefully chosen when a GNSS receiver is designed for a target application, and different considerations are made on the choices and trade-offs involved.

Furthermore, in order for a GNSS receiver to be able to provide the required solution, the specification team should have a clear knowledge of the system as a whole, with special focus on the space segment (satellites, RF signals, modulations and bandwidths) and user segment (hardware, receivers and applications). At system design level, it is the interface between these two segments that is targeted, and a receiver is tailored not only to provide PVT (or other) solutions, but also to take full advantage of the characteristics of the signals received and their respective transmitting satellite constellation(s).

Block diagram

The figure shows the main blocks inside a GNSS receiver system, as they represent most of the dimensioning and engineering work involved in a receiver system specification and design. These different subsets, from a functional point of view, can be categorized as antenna, front end, baseband processing and applications processing, and are shortly described as[1]:

Figure 1: Block diagram of a typical GNSS receiver, illustrating the different parallel processing channels.
  • Antenna: L-band antenna for capturing GNSS signals, with the associated amplification and filtering. It represents the entry point from the space segment to the user segment, and receives the L-band signals to pre-process and feed as an analog electrical signal to the front end (still as a 1.2 - 1.6 GHz range RF signal).
  • Front End: The front end section receives the RF inputs from the antenna, and performs down-conversion, filtering / amplification, and sampling (digitizing) of the captured signals. Typically in a superheterodyne[2] configuration, the front end converts the analog GNSS signals to digital data streams in an intermediate frequency (IF) spectrum (centered in the MHz range), and finally to a baseband digital signal in-phase (I) and quadrature (Q) components.
  • Baseband processing: All acquisition and tracking signal processing tasks are performed in the baseband processing blocks, where the core functions that enable GNSS signal tracking occur, such as correlations, delay/frequency/phase lock loops, filtering, and others. Receivers typically process several channels in parallel, where different signals are tracked, and produce observables like code delay, carrier phase, and Doppler frequency, as measurement data.
  • Applications Processing: Since the target application for a receiver can vary, the applications processing block is designed to extract the GNSS measurements, observables, and navigation data, and compute the desired solutions - for instance, the position of the user on Earth. For this purpose, the receiver combines the outputs of the signal processing algorithms in order to extract the navigation message and other information necessary for PVT computation.

Design considerations

From a system design perspective, there isn't a real set of "rules of thumb" to chose a given approach for a GNSS receiver design. In fact, the requirements are strongly influenced by the application itself, whether in terms of architecture or performance. Below are a few examples[3] of the requirements, analysis and tradeoffs involved:

  • Environmental Constraints: Factors such as temperature, humidity, water resistance, shock and vibration ranges depend on the application. Furthermore, the surrounding environment can also impact the design in terms of performance, e.g. urban environments can originate several multipath signals, where the reflection of GNSS signals on surrounding surfaces generates a non-line-of-sight ray. In the latter case, multipath mitigation signal-processing techniques may be required.
  • Precision and Accuracy: Higher precision is required, for instance, in survey or military operations, whereas automotive or mobile applications may not require centimeter-level precision. As another example, the solution accuracy, precision, and rate are surely different for aircraft precision approach, than for marine or automotive navigation.
  • Single/Multi Frequency/Constellation: An increasing range of GNSS frequencies, bands, modulations and constellations enable a multitude of possibilities in receiver design, from single frequency / single constellation (e.g. the common GPS L1 C/A devices on current PND's or smartphones) to multi-frequency / multi-constellation (e.g. L-band GPS/Galileo/GLONASS capable high-end survey receivers).
  • Assisting Sources: Several external or assistance information sources can be taken into account at system design, since there is a straightforward impact on resources and solution computation. If the use of augmentation (SBAS) or differential (DGPS) data is envisaged, the receiver must be prepared to interface and use the information provided from such systems. Other external interfaces and aiding sensors can be coupled to a receiver, such as inertial sensors[4] (IMU and INS), or even the means to get external aiding information (e.g. accessing the internet through WiFi or GPRS/UMTS).
  • Hardware Platform: On a physical platform point of view, several design considerations are made in terms of the hardware host platform, user interface design, storage capability, power/battery consumption, electromagnetic compatibility, or portability. The underlying platform for a GNSS receiver can be an ASIC, FPGA, DSP, CPU, hardware/software defined, or a combination of these and other technologies. Table 1[5] below shows an assessment of the advantages and disadvantages of each approach.


Table 1: GNSS technology comparison, from (++) major advantage to (--) major disadvantage.
Technology Development Costs Performance Power Consumption Single Unit Costs Flexibility
ASIC -- ++ ++ ++ --
FPGA - ++ + - +
DSP / CPU ++ + / ++ + / -- + / - ++
Hybrid FPGA / CPU + ++ + - +

Related articles

References

  1. ^ For further details, refer to their corresponding articles (links provided in the "Related articles" section).
  2. ^ wikipedia:Superheterodyne receiver
  3. ^ For another example on receiver design considerations, see Kaplan, E.D. et al, "Understanding GPS: Principles and Applications", second edition, chapter 3, section 3.4.
  4. ^ wikipedia:Inertial measurement unit
  5. ^ Hein, G., Pany, T., Wallner, S., Won, J., "Platforms for a future GNSS receiver - A discussion of ASIC, FPGA, and DSP technologies", Working Papers, InsideGNSS, March 2006.