If you wish to contribute or participate in the discussions about articles you are invited to contact the Editor
Receiver Characteristics: Difference between revisions
No edit summary |
No edit summary |
||
(20 intermediate revisions by 6 users not shown) | |||
Line 1: | Line 1: | ||
{{Article Infobox2 | {{Article Infobox2 | ||
|Category=Receivers | |Category=Receivers | ||
| | |Editors=GMV | ||
|Level=Intermediate | |||
|Level= | |||
|YearOfPublication=2011 | |YearOfPublication=2011 | ||
|Logo=GMV | |Logo=GMV | ||
|Title={{PAGENAME}} | |||
}} | }} | ||
Receiver characteristics and [[System Design Details|design]] are strongly related to the application at hand. In fact, the target application requirements are actually the main driver to a given receiver architecture and design decisions, so the selection of an adequate receiver usually underlies a large set of trade-offs. | |||
Receiver characteristics and [[System Design Details|design]] are strongly related to the application at hand. In fact, the target application requirements are actually the main driver to a given receiver architecture and design decisions | |||
==Environmental Constraints== | ==Environmental Constraints== | ||
The surrounding environment influences the receiver behaviour in terms of performance. Some examples are: | |||
*<b>Multipath</b>: GNSS signals can be affected by multipath, whenever the reflection of the SIS signal on surrounding surfaces distorts the received signal, or even generates a non-line-of-sight (NLOS) ray. Multipath mitigation techniques may be implemented in the receiver, at the cost of increasing the processing load. Conversely, it may be beneficial to process NLOS reflected signals for improving availability while sacrificing accuracy. The trade-off "availability vs accuracy" will rely mainly on the receiver application. For non-critical road applications in urban environments, for instance, availability may be more important than accuracy, since the receiver often makes use of map matching techniques to extrapolate its position, and therefore tracking of NLOS may come as a design decision, despite the large errors introduced in the final solution. | |||
*<b>Multipath</b>: GNSS signals can be affected by multipath, whenever the reflection of the SIS signal on surrounding surfaces distorts the received signal or even generates a non-line-of-sight ray. Multipath mitigation techniques may be implemented in the receiver, at the cost of increasing the processing load. Conversely, it may be beneficial to process NLOS reflected signals for improving availability while sacrificing accuracy. The trade-off | |||
*<b>Interference</b>: in some applications it may be possible to predict that a certain type of interference will be present in some locations. An example is the case of aeronautical applications, where it is foreseen that TACAN/ DME beacons will cause pulse interference in the L5/ E5a band. In this case, the receiver may consider including techniques | *<b>Interference</b>: in some applications, it may be possible to predict that a certain type of interference will be present in some locations. An example is the case of [[Aviation Applications|aeronautical applications]], where it is foreseen that TACAN / DME beacons will cause pulse interference in the L5 / E5a band. In this case, the receiver may consider including techniques for pulse interference mitigation in the [[Front End|front end]]. Another example to be considered is the case of some military applications that use [[Antennas|antenna arrays]] and beam-forming techniques to insert nulls in the radiation diagram of the antenna in the direction of an interferer, whose position is known a-priori or detected dynamically. | ||
*<b>Atmospheric</b>: | *<b>Atmospheric</b>: atmospheric delays that affect the signal during its propagation have a significant impact on the accuracy of the receiver measurements. Therefore, the solution accuracy is directly linked to the receiver’s ability to correct for such delays. The most significant atmospheric delays are caused by the [[Ionospheric Delay|ionosphere]] and the [[Tropospheric Delay|troposphere]]. | ||
*<b>Operation Conditions</b>: Factors such as temperature, humidity, water resistance, shock and vibration ranges depend on the application. This has an influence not only on the choice of the platform (see below), but also on the casing (e.g. ruggedization, radome) and applicable standards (e.g. if subject to certification). As an example, space receivers will have to cope with huge levels of vibration (e.g. during launch) and they will be submitted to highly inauspicious environments (e.g. radiations in space). | *<b>Operation Conditions</b>: Factors such as temperature, humidity, water resistance, shock and vibration ranges depend on the application. This has an influence not only on the choice of the platform (see below), but also on the casing (e.g. ruggedization, radome) and applicable standards (e.g. if subject to certification). As an example, space receivers will have to cope with huge levels of vibration (e.g. during launch) and they will be submitted to highly inauspicious environments (e.g. radiations in space). | ||
==Application Constraints== | ==Application Constraints== | ||
*<b>Receiver Dynamics</b>: receiver dynamics may affect the received signal (e.g. increasing the range of Doppler frequencies of the incoming signals). In such applications, the design of the receiver needs to cope with such requirements. As an example, a stationary receiver is expected to handle Doppler frequencies within the range of ±4 kHz, but this value is largely exceeded in GPS-guided ballistic applications. These considerations will also have an impact on the [[Tracking Loops|tracking loops]] since the integration times must take these factors into consideration. | *<b>Receiver Dynamics</b>: receiver dynamics may affect the received signal (e.g. increasing the range of Doppler frequencies of the incoming signals). In such applications, the design of the receiver needs to cope with such requirements. As an example, a stationary receiver is expected to handle Doppler frequencies within the range of ±4 kHz, but this value is largely exceeded in GPS-guided ballistic applications. These considerations will also have an impact on the [[Tracking Loops|tracking loops]], since the integration times must take these factors into consideration. | ||
*<b>Military applications</b>: legacy military applications use the [[GPS | *<b>Military applications</b>: legacy military applications use the [[GPS Services|GPS Precise Position Service (PPS)]] which implies encryption capabilities and dual frequency receivers. Furthermore, (un)intentional interference is a major concern for military applications, since the receiver will likely have to operate in an environment where jammers and spoofers are present. Interference mitigation techniques are therefore usually welcomed for these applications. | ||
*<b>Aeronautical applications</b>: the main challenge in the aeronautical domain is | *<b>Aeronautical applications</b>: the main challenge in the aeronautical domain is concerning the landing and taking-off phases, not only due to the required accuracy but mostly because of the need for integrity, since it is a safety critical application. Furthermore, interference in the aeronautical band is expected in most airport vicinities, e.g. DME / TACAN pulses in the L5 band. | ||
*<b>Professional applications</b>: professional applications usually have sub-metric accuracy requirements. In addition, end-users use accurate GNSS receiver solutions for a final purpose (e.g. [[Precision Agriculture|precision agriculture]] and [[Space-time Metrology|space-time metrology]]). | *<b>Professional applications</b>: professional applications usually have sub-metric accuracy requirements. In addition, end-users use accurate GNSS receiver solutions for a final purpose (e.g. [[Precision Agriculture|precision agriculture]] and [[Space-time Metrology|space-time metrology]]). These applications often require a great deal of dedicated software customisation, mostly in the [[System Design Details#Applications Processing|application block]], to ensure the interface between the receiver and the final user. | ||
==Receiver Processing== | |||
From a physical 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. Common underlying platforms for a GNSS receiver are 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 the comparative analysis of the platform technologies. | From a physical 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. Common underlying platforms for a GNSS receiver are 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 the comparative analysis of the platform technologies. | ||
{| class="wikitable" align="center" | |||
{| | |+align="bottom"|Table 1: GNSS technology comparison, from (++) major advantage to (--) major disadvantage. | ||
|+align="bottom | |||
|- | |- | ||
| | !Technology | ||
!Development Costs | |||
!Performance | |||
!Power Consumption | |||
!Single Unit Costs | |||
!Flexibility | |||
|- align="center" | |||
!ASIC | |||
| -- | |||
| ++ | |||
| ++ | |||
| ++ | |||
| -- | |||
|- align="center" | |||
!FPGA | |||
| - | |||
| ++ | |||
| + | |||
| - | |||
| + | |||
|- align="center" | |||
!DSP / CPU | |||
| ++ | |||
| + / ++ | |||
| + / -- | |||
| + / - | |||
| ++ | |||
|- align="center" | |||
!Hybrid FPGA / CPU | |||
| + | |||
| ++ | |||
| + | |||
| - | |||
| + | |||
|} | |} | ||
The receiver platform along with its hardware components will also have an impact on the accuracy of the measurements provided by the receiver. In fact, the receiver hardware is also a source of inaccuracies adding thermal noise and inter-channel biases. Furthermore, the receiver measurements are limited by the resolution of the underlying hardware platform. | The receiver platform, along with its hardware components, will also have an impact on the accuracy of the measurements provided by the receiver. In fact, the receiver hardware is also a source of inaccuracies by adding thermal noise and inter-channel biases. Furthermore, the receiver measurements are limited by the resolution of the underlying hardware platform. | ||
More details on the receiver processing stages and most common implementations are available [[System Design Details|here]]. | |||
==Performance== | ==Performance== | ||
As far as [[GNSS Performances|GNSS receiver | As far as [[GNSS Performances|GNSS receiver performance]] goes: | ||
*<b>Availability</b>: | *<b>Availability</b>: whenever availability is the main driver, using multi-constellations is usually a cheap solution (due to the interoperability among the different systems), and in principle it will increase the number of satellites in view in harsh environments such as urban canyons. Using aiding sensors such as inertial sensors (INS)<ref>[[wikipedia:Inertial navigation system|Inertial Navigation System on Wikipedia]]</ref> may also improve overall availability, since the receiver may still be able to provide a solution even if a GNSS solution is not available at that time instant. | ||
*<b>Continuity</b>: whenever solution continuity is a key driver, the receiver may accommodate dedicated algorithms, e.g. guaranteeing extrapolation of the solution (even if a GNSS solution is not present) using past measurements, external sensors (e.g. INS), or even complementary technology (e.g. UMTS, WiFi). | |||
*<b>Integrity</b>: although integrity is usually associated with aeronautical applications, [[Criticality of GNSS Applications|liability-critical applications]] also share this need. For safety-critical applications, the receiver may cope with integrity by using [[SBAS Fundamentals|SBAS]] and Galileo. For the remaining applications where integrity may be required, the receiver may still use SBAS, but there are also alternative receiver standalone techniques that can be implemented (less stringent), such as Isotropy-Based Protection Levels (IBPL)<ref>Cosmen-Schortmann, J.; Azaola-Saenz, M.; Martinez-Olague, M.A.; Toledo-Lopez, M.; <i>“Integrity in urban and road environments and its use in liability critical applications”</i>, GMV, Position, Location and Navigation Symposium, 2008 IEEE/ION, 5-8 May 2008, page(s): 972 – 983, Monterey, CA.</ref>. | |||
*<b>Accuracy</b>: whenever accuracy is the main driver, receiver designers and manufacturers may decide to choose from a wide range of techniques such as [[Differential GNSS|Differential GNSS]], [[PPP Fundamentals|Precise Point Positioning (PPP)]] or [[Real Time Kinematics|Real Time Kinematic]]. | |||
As an example of the different error magnitudes, depending on the receiver application, Table 2<ref><i>Kaplan, E.D. et al, "Understanding GPS: Principles and Applications", second edition, chapter 7, section 7.7</i>.</ref> presents an order of magnitude of the 3-D position / time errors achieved with different types of receivers, both for Standard Positioning Service (SPS) and Precise Positioning Service (PPS) using legacy GPS. Note that this table is valid for GPS only and it is provided here for illustrative purposes<ref>For further information on the accuracy of each of the GNSS, please refer to the applicable sections.</ref>. | |||
{| | {| class="wikitable" align="center" | ||
|+align="bottom | |+align="bottom"|Table 2: Comparative 95% three-dimensional position / time errors across various receivers. | ||
|- | |- | ||
! | ! | ||
!colspan="3"|SPS | |||
!colspan="3"|PPS | |||
|- | |- | ||
! | |||
!Best Location | |||
!Median Location | |||
!Worst Location | |||
!Best Location | |||
!Median Location | |||
!Worst Location | |||
|- align="center" | |||
!Handheld (best 4-SV solution) | |||
|16m | |||
|32m | |||
|72m | |||
|10m | |||
|30m | |||
|71m | |||
|- align="center" | |||
!Handhelp (AIV solution) | !Handhelp (AIV solution) | ||
|11m | |11m | ||
|- | |25m | ||
|54m | |||
|8m | |||
|23m | |||
|53m | |||
|- align="center" | |||
!Mobile (land/marine vehicle) | !Mobile (land/marine vehicle) | ||
|7m | |7m | ||
|- | |23m | ||
|53m | |||
|N/A | |||
|N/A | |||
|N/A | |||
|- align="center" | |||
!Aviation receiver (AIV, RAIM, tightly coupled with INS) | !Aviation receiver (AIV, RAIM, tightly coupled with INS) | ||
|7m | |7m | ||
|- | |24m | ||
|55m | |||
|4m | |||
|5m | |||
|6m | |||
|- align="center" | |||
!Survey receiver (dual-frequency, real-time performance) | !Survey receiver (dual-frequency, real-time performance) | ||
|3m | |3m | ||
|- | |4m | ||
|5m | |||
|3m | |||
|4m | |||
|5m | |||
|- align="center" | |||
!Aviation receiver dynamic time transfer performance | !Aviation receiver dynamic time transfer performance | ||
|14ns | |14ns | ||
|- | |45ns | ||
|105ns | |||
|12ns | |||
|13ns | |||
|14ns | |||
|- align="center" | |||
!Time transfer receiver static time transfer performance | !Time transfer receiver static time transfer performance | ||
|10ns | |10ns | ||
|19ns | |||
|35ns | |||
|10ns | |||
|10ns | |||
|11ns | |||
|} | |} | ||
Line 102: | Line 166: | ||
*[[GNSS Receivers General Introduction]] | *[[GNSS Receivers General Introduction]] | ||
*[[Generic Receiver Description]] | *[[Generic Receiver Description]] | ||
*[[System Design Details]] | |||
==References== | ==References== | ||
<references/> | <references/> | ||
[[Category:Receivers]] | [[Category:Receivers]] |
Latest revision as of 18:59, 2 September 2018
Receivers | |
---|---|
Title | Receiver Characteristics |
Edited by | GMV |
Level | Intermediate |
Year of Publication | 2011 |
Receiver characteristics and design are strongly related to the application at hand. In fact, the target application requirements are actually the main driver to a given receiver architecture and design decisions, so the selection of an adequate receiver usually underlies a large set of trade-offs.
Environmental Constraints
The surrounding environment influences the receiver behaviour in terms of performance. Some examples are:
- Multipath: GNSS signals can be affected by multipath, whenever the reflection of the SIS signal on surrounding surfaces distorts the received signal, or even generates a non-line-of-sight (NLOS) ray. Multipath mitigation techniques may be implemented in the receiver, at the cost of increasing the processing load. Conversely, it may be beneficial to process NLOS reflected signals for improving availability while sacrificing accuracy. The trade-off "availability vs accuracy" will rely mainly on the receiver application. For non-critical road applications in urban environments, for instance, availability may be more important than accuracy, since the receiver often makes use of map matching techniques to extrapolate its position, and therefore tracking of NLOS may come as a design decision, despite the large errors introduced in the final solution.
- Interference: in some applications, it may be possible to predict that a certain type of interference will be present in some locations. An example is the case of aeronautical applications, where it is foreseen that TACAN / DME beacons will cause pulse interference in the L5 / E5a band. In this case, the receiver may consider including techniques for pulse interference mitigation in the front end. Another example to be considered is the case of some military applications that use antenna arrays and beam-forming techniques to insert nulls in the radiation diagram of the antenna in the direction of an interferer, whose position is known a-priori or detected dynamically.
- Atmospheric: atmospheric delays that affect the signal during its propagation have a significant impact on the accuracy of the receiver measurements. Therefore, the solution accuracy is directly linked to the receiver’s ability to correct for such delays. The most significant atmospheric delays are caused by the ionosphere and the troposphere.
- Operation Conditions: Factors such as temperature, humidity, water resistance, shock and vibration ranges depend on the application. This has an influence not only on the choice of the platform (see below), but also on the casing (e.g. ruggedization, radome) and applicable standards (e.g. if subject to certification). As an example, space receivers will have to cope with huge levels of vibration (e.g. during launch) and they will be submitted to highly inauspicious environments (e.g. radiations in space).
Application Constraints
- Receiver Dynamics: receiver dynamics may affect the received signal (e.g. increasing the range of Doppler frequencies of the incoming signals). In such applications, the design of the receiver needs to cope with such requirements. As an example, a stationary receiver is expected to handle Doppler frequencies within the range of ±4 kHz, but this value is largely exceeded in GPS-guided ballistic applications. These considerations will also have an impact on the tracking loops, since the integration times must take these factors into consideration.
- Military applications: legacy military applications use the GPS Precise Position Service (PPS) which implies encryption capabilities and dual frequency receivers. Furthermore, (un)intentional interference is a major concern for military applications, since the receiver will likely have to operate in an environment where jammers and spoofers are present. Interference mitigation techniques are therefore usually welcomed for these applications.
- Aeronautical applications: the main challenge in the aeronautical domain is concerning the landing and taking-off phases, not only due to the required accuracy but mostly because of the need for integrity, since it is a safety critical application. Furthermore, interference in the aeronautical band is expected in most airport vicinities, e.g. DME / TACAN pulses in the L5 band.
- Professional applications: professional applications usually have sub-metric accuracy requirements. In addition, end-users use accurate GNSS receiver solutions for a final purpose (e.g. precision agriculture and space-time metrology). These applications often require a great deal of dedicated software customisation, mostly in the application block, to ensure the interface between the receiver and the final user.
Receiver Processing
From a physical 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. Common underlying platforms for a GNSS receiver are ASIC, FPGA, DSP, CPU, hardware/software defined, or a combination of these (and other) technologies. Table 1[1] below shows the comparative analysis of the platform technologies.
Technology | Development Costs | Performance | Power Consumption | Single Unit Costs | Flexibility |
---|---|---|---|---|---|
ASIC | -- | ++ | ++ | ++ | -- |
FPGA | - | ++ | + | - | + |
DSP / CPU | ++ | + / ++ | + / -- | + / - | ++ |
Hybrid FPGA / CPU | + | ++ | + | - | + |
The receiver platform, along with its hardware components, will also have an impact on the accuracy of the measurements provided by the receiver. In fact, the receiver hardware is also a source of inaccuracies by adding thermal noise and inter-channel biases. Furthermore, the receiver measurements are limited by the resolution of the underlying hardware platform.
More details on the receiver processing stages and most common implementations are available here.
Performance
As far as GNSS receiver performance goes:
- Availability: whenever availability is the main driver, using multi-constellations is usually a cheap solution (due to the interoperability among the different systems), and in principle it will increase the number of satellites in view in harsh environments such as urban canyons. Using aiding sensors such as inertial sensors (INS)[2] may also improve overall availability, since the receiver may still be able to provide a solution even if a GNSS solution is not available at that time instant.
- Continuity: whenever solution continuity is a key driver, the receiver may accommodate dedicated algorithms, e.g. guaranteeing extrapolation of the solution (even if a GNSS solution is not present) using past measurements, external sensors (e.g. INS), or even complementary technology (e.g. UMTS, WiFi).
- Integrity: although integrity is usually associated with aeronautical applications, liability-critical applications also share this need. For safety-critical applications, the receiver may cope with integrity by using SBAS and Galileo. For the remaining applications where integrity may be required, the receiver may still use SBAS, but there are also alternative receiver standalone techniques that can be implemented (less stringent), such as Isotropy-Based Protection Levels (IBPL)[3].
- Accuracy: whenever accuracy is the main driver, receiver designers and manufacturers may decide to choose from a wide range of techniques such as Differential GNSS, Precise Point Positioning (PPP) or Real Time Kinematic.
As an example of the different error magnitudes, depending on the receiver application, Table 2[4] presents an order of magnitude of the 3-D position / time errors achieved with different types of receivers, both for Standard Positioning Service (SPS) and Precise Positioning Service (PPS) using legacy GPS. Note that this table is valid for GPS only and it is provided here for illustrative purposes[5].
SPS | PPS | |||||
---|---|---|---|---|---|---|
Best Location | Median Location | Worst Location | Best Location | Median Location | Worst Location | |
Handheld (best 4-SV solution) | 16m | 32m | 72m | 10m | 30m | 71m |
Handhelp (AIV solution) | 11m | 25m | 54m | 8m | 23m | 53m |
Mobile (land/marine vehicle) | 7m | 23m | 53m | N/A | N/A | N/A |
Aviation receiver (AIV, RAIM, tightly coupled with INS) | 7m | 24m | 55m | 4m | 5m | 6m |
Survey receiver (dual-frequency, real-time performance) | 3m | 4m | 5m | 3m | 4m | 5m |
Aviation receiver dynamic time transfer performance | 14ns | 45ns | 105ns | 12ns | 13ns | 14ns |
Time transfer receiver static time transfer performance | 10ns | 19ns | 35ns | 10ns | 10ns | 11ns |
Related articles
References
- ^ 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.
- ^ Inertial Navigation System on Wikipedia
- ^ Cosmen-Schortmann, J.; Azaola-Saenz, M.; Martinez-Olague, M.A.; Toledo-Lopez, M.; “Integrity in urban and road environments and its use in liability critical applications”, GMV, Position, Location and Navigation Symposium, 2008 IEEE/ION, 5-8 May 2008, page(s): 972 – 983, Monterey, CA.
- ^ Kaplan, E.D. et al, "Understanding GPS: Principles and Applications", second edition, chapter 7, section 7.7.
- ^ For further information on the accuracy of each of the GNSS, please refer to the applicable sections.