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
Rui.Sarnadas (talk | contribs) No edit summary |
Rui.Sarnadas (talk | contribs) No edit summary |
||
Line 9: | Line 9: | ||
In order to process the [[GNSS signal|L-band signals]] transmitted from the satellites and compute the navigation solution, a GNSS receiver can be designed to target different [[GNSS Applications|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. | In order to process the [[GNSS signal|L-band signals]] transmitted from the satellites and compute the navigation solution, a GNSS receiver can be designed to target different [[GNSS Applications|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== | ==Overview== | ||
Line 15: | Line 14: | ||
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 [[GNSS Measurements Modelling|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). | 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 [[GNSS Measurements Modelling|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== | ==Block diagram== | ||
Line 29: | Line 27: | ||
*<b>Applications Processing</b>: 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. | *<b>Applications Processing</b>: 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== | ==Design considerations== | ||
Line 58: | Line 55: | ||
| '''Hybrid FPGA / CPU''' || + || ++ || + || - || + | | '''Hybrid FPGA / CPU''' || + || ++ || + || - || + | ||
|} | |} | ||
==Related articles== | ==Related articles== | ||
Line 67: | Line 63: | ||
*[[Baseband Processing]] | *[[Baseband Processing]] | ||
*[[Applications Processing]] | *[[Applications Processing]] | ||
==References== | ==References== | ||
<references/> | <references/> | ||
[[Category:Receivers]] | [[Category:Receivers]] |
Revision as of 16:05, 7 April 2011
Receivers | |
---|---|
Title | System Design Details |
Author(s) | GMV |
Level | Medium |
Year of Publication | 2011 |
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]:
- 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.
Technology | Development Costs | Performance | Power Consumption | Single Unit Costs | Flexibility |
---|---|---|---|---|---|
ASIC | -- | ++ | ++ | ++ | -- |
FPGA | - | ++ | + | - | + |
DSP / CPU | ++ | + / ++ | + / -- | + / - | ++ |
Hybrid FPGA / CPU | + | ++ | + | - | + |
Related articles
- Generic Receiver Description
- Receiver Types
- Antennas
- Front End
- Baseband Processing
- Applications Processing
References
- ^ For further details, refer to their corresponding articles (links provided in the "Related articles" section).
- ^ http://en.wikipedia.org/wiki/Superheterodyne_receiver
- ^ 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.
- ^ http://en.wikipedia.org/wiki/Inertial_measurement_unit
- ^ 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.