Download presentation
Presentation is loading. Please wait.
Published byGwenda Willis Modified over 9 years ago
1
GNSS Background for OPUS Projects Gerald L. Mader National Geodetic Survey Silver Spring, MD 2014-05-291GNSS Background
2
Background Before we begin the OPUS Projects training, it would be a good idea to go over some background on GNSS. Although these concepts are valid for any GNSS, occasionally we’ll explicitly discuss GPS, the only GNSS currently used in OPUS. This is not a review of the equations, but rather a discussion of the qualitative factors that affect precision and accuracy. This should help explain why-we-do-what-we-do and how to use OPUS Projects wisely. 2014-05-292GNSS Background
3
GPS Signals Pseudo Random Noise (PRN) code Carrier phase Your receiver records GPS pseudo-range and carrier phase at 2 frequencies: L1 and L2. These data are contained in the RINEX file. Carrier phase has an unknown initial integer bias that must be determined. 2014-05-293GNSS Background
4
RINEX File There are only two characteristics of a RINEX file that really matter: Where the data was collected. We may need to know available references for the relative positioning. Observation span of the data Determines the technique for finding the phase biases. – Ambiguity search for short baseline/short span. – Least squares for longer baselines/ longer spans. Determines the precision of position solutions. 2014-05-294GNSS Background
5
RINEX File A single RINEX file is sufficient to get a position. Pseudo-range point positions: ̴10m. Carrier phase Precise Point Position (PPP): ̴cm’s. Why doesn’t OPUS do PPP positioning? Long convergence times. Harder to get integer biases. Positions not necessarily in NSRS or relative to passive control. 2014-05-295GNSS Background
6
Relative Positioning OPUS, including OPUS Projects, uses relative positioning. The phase data between 2 receivers is explicitly differenced. The 2 nd receiver is usually a reference at known position. Gives the position of 1 st mark relative to the 2 nd. 2014-05-296GNSS Background
7
Relative Positioning Why do relative positioning? Positions can be computed with respect to known marks in NSRS. Mitigates any orbit error, and ionospheric and tropospheric propagation effects. Phase biases are still integers. The connection between the 2 marks will be referred to as the baseline. Be aware that OPUS Projects requires you to identify the mark(s) to which your project mark positions will be relative. 2014-05-297GNSS Background
8
Baseline Length What is the impact of the separation between these 2 marks, A.K.A. baseline length? The principle factors that affect precision as a function of baseline length are: GNSS orbit accuracy. Signal propagation. 2014-05-298GNSS Background
9
GNSS Orbit Accuracy An old rule-of-thumb says the effect of orbital errors scales by the ratio of the baseline length to the satellite distance. For the example here, that ratio would be: OPUS uses the orbits produced by the IGS which are accurate to better than 5 cm. The likely effect of orbit accuracy on positions computed by OPUS is 5 cm 0.01 = 0.05 cm Less than a mm – in other words, orbit error is not a significant factor. 200 km baseline GPS satellites approximately 20,000 km above earth 200 km 20000 km = 0.01 2014-05-299GNSS Background
10
Signal Propagation As GNSS signals pass through the Earth's atmosphere, they are distorted. These distortions are called signal propagation effects. The offending parts of the atmosphere are commonly called the ionosphere (charged) and the troposphere (neutral), and their corrections are handled differently. 2014-05-2910GNSS Background www.windows.ucar.edu/spaceweather/images/atmos_layers_new_gif_image.html
11
Signal Propagation When baseline lengths are very short, the signal distortions suffered at each mark are very similar and differencing, like that done in OPUS, removes these effects. 2014-05-2911GNSS Background But as the baseline length increases, the signal distortions at each mark becomes increasingly different and other techniques must be employed to correct them.
12
Ionosphere Outermost layer of the Earth's atmosphere. Contains positively charged atoms and negatively charged electrons. Caused by solar radiation. Strong day/night effect (diurnal). Charge density is highly variable. Limits the distance over which single frequency GNSS is usable. 2014-05-2912GNSS Background
13
Ionosphere Effect on GNSS signals depends on frequency. GPS is designed with 2 frequencies, L1 & L2, to correct for ionosphere effect. L1 & L2 data can be combined to form an ionosphere-free, or ion-free for short, linear combination (L3 in PAGES jargon). Ion-free combination eliminates ionospheric effect. 2014-05-2913GNSS Background
14
Ionosphere Because the ion-free combination includes two measurements (L1 & L2), it is noisier than either single frequency measurement. So, L1-only is preferred on very short baselines where ionospheric effects are eliminated by differencing. (The increased noise of L3 can be greater than the correction.) But this requires a rule about what distance to switch from L1-only to ion-free. Such rules are imperfect and discrete transitions are problematic. 2014-05-2914GNSS Background
15
Ionosphere OPUS Projects solves the L1-only to ion-free transition problem by using the L6 (in PAGES jargon) combination: L6 = L1 + w * ion(L1,L2) where ion(L1,L2) is the ion-free correction and w goes from 0 to 1 depending upon baseline length. The function w was designed such that most of the transition occurs from 5 to 15 km. This gradually applies the ionospheric correction as a function of baseline length, so OPUS Projects users need not worry about ionosphere. 2014-05-2915GNSS Background
16
Troposphere The troposphere has 2 components: Hydrostatic (or dry) - major component. Wet (water vapor) - minor component. The hydrostatic component is very well modeled from surface pressure derived from a global, seasonal model. The wet component can be highly variable and cannot be modeled well. 2014-05-2916GNSS Background
17
Troposphere Elevation Models estimate tropo delay at zenith (approx. 2.3m at sea level). A mapping function then scales the zenith value of tropo delay as a function of elevation. OPUS Projects adjusts the wet zenith value of the tropospheric delay at each mark. These corrections are typically a few cm (when done correctly). 2014-05-2917GNSS Background
18
Troposphere Azimuthal Symmetry 15° 8 km ̴ 30 km 2 km ̴ 8 km The troposphere has a scale height of about 8 km (the height at which the density drops by 1/e or by about 63%). For an elevation cutoff of 15°, typical for OPUS Projects, we’re assuming the troposphere is symmetric out to a radius of ̴30km around each mark. The scale height for the water vapor is about 2 km. So for a 15° elevation cutoff, the signal path will be above most of the water vapor beyond a radius of about 8 km. The assumption of azimuthal symmetry, while not perfect, should be fine in almost all cases except near marine boundaries or for fast moving fronts. But even in these exceptions, it is still very good. 2014-05-2918GNSS Background
19
Troposphere Numerical Issues Nearby marks see the same satellites at nearly the same elevation making it difficult, numerically, to resolve these tropo corrections. This can result in “bad” tropo corrections and consequently suspicious heights. Including data from a mark, or marks, sufficiently distant that the same satellites are seen at significantly different elevations will resolve these numerical problems resulting in “better” tropo corrections and more reliable heights. 2014-05-2919GNSS Background
20
Troposphere Corrections A general qualitative scheme for tropo corrections on baselines of varying lengths would be: Very short length: no tropo correction on either mark. Moderate length: correction at 1 mark (relative tropo). Very long length: corrections at both marks (absolute tropos). However this would require rules for distances to impose these discrete transitions – difficult to describe for all cases thereby creating an unnecessary burden on users. 2014-05-2920GNSS Background
21
Troposphere Corrections A simple alternative is to always include a distant mark. The availability of CORS makes this universally applicable. OPUS Projects makes it easy to select and add CORS to all sessions (if not already there). 2014-05-2921GNSS Background
22
Troposphere Corrections OPUS Projects recommends including one or several distant marks (>1000km) to stabilize the tropo corrections. This probably seems counter-intuitive for projects covering small areas; however, the alternative, trying to subjectively judge what type of tropo corrections should be applied, has risks and often results in inconsistent processing strategies within a project. 2014-05-2922GNSS Background
23
Troposphere Corrections bm02 ZEN WET 13/05/01 18:00:00.00 -0.30152(0.04131)M.10+01 73 bm02 ZEN WET 13/05/01 20:00:00.00 0.15089(0.01159)M.76+00 73 bm02 ZEN WET 13/05/01 22:00:00.00 0.25114(0.01326)M.91+00 73 bm02 ZEN WET 13/05/02 00:00:00.00 -0.17600(0.01359)M.80+00 73 bm02 ZEN WET 13/05/01 18:00:00.00 0.05276(0.00456)M.10+01 151 bm02 ZEN WET 13/05/01 20:00:00.00 0.04918(0.00117)M.74+00 151 bm02 ZEN WET 13/05/01 22:00:00.00 0.05602(0.00107)M.90+00 151 bm02 ZEN WET 13/05/02 00:00:00.00 0.02847(0.00140)M.72+00 151 50km baseline without distant mark 50km baseline with distant mark “Poor” tropo corrections 23 “Good” Tropo corrections Here is an example of tropo corrections from the processing logs for a 50 km baseline with and without including a distant mark. The improvement when the distant mark is included is clear. Tropo corrections estimated every 2 hr 2014-05-2923GNSS Background
24
Baseline Length After all that discussion it turns out that baseline length is not a factor for processing. The CORS selected as a reference mark, for example, need not necessarily be the closest CORS. However, there is another consideration that depends on baseline length. 2014-05-2924GNSS Background
25
Mutual Visibility For a variety of reasons, only observations above a specified elevation angle are used in processing. This elevation cutoff is typically 12 – 15 and is specified as part of the OPUS Project processing. Because OPUS Projects uses differential processing, only satellite observations above the elevation cutoff at both ends of a baseline will be used. This is called mutual visibility. Due to the Earth's curvature, the amount of unusable data increases with baseline length. 2014-05-2925GNSS Background
26
Mutual Visibility About how much data is unusable with baseline length? If a baseline is about 110 km in length, a satellite will appear to have about a 1° difference in elevation from the ends of a baseline when looking “down” the baseline’s length. Less off to side of baseline. To get an idea how much data is lost at the 1 st mark while waiting for satellite to clear the cutoff at the 2 nd mark, suppose a rising satellite is at the elevation cutoff at the 1 st mark, but only 1° below the cutoff at the 2 nd. Maximum satellite movement of 30°/hr implies at least 2 min of data lost. For satellites not reaching zenith (slower movement), data loss of 4-5 min is more typical. 2014-05-2926GNSS Background
27
Mutual Visibility For data spans of 2 hr, a 5 min data loss, or about 4%, is generally considered tolerable. To keep data loss < 5%, baseline lengths should not exceed roughly 100 km. If this is not possible, longer occupations may be necessary to compensate. 2014-05-2927GNSS Background
28
Baseline Length Considerations Shorter baselines have more observations. Longer baselines improve tropo estimations. OPUS Projects processing can, with the appropriate processing strategy, optimize these factors along with relative precision of project marks and accuracy within the NSRS. 2014-05-2928GNSS Background
29
A New Paradigm GNSS projects have inherent characteristics that are very different from those of optically measured geodetic networks These differences provide an opportunity to rethink how projects should be processed
30
Optical Surveys In a survey done with conventional optical survey tools, a total station for example, the marks of the network are connected by direct measurement of angles and distances. These measurements are inseparable from the marks they connect. This creates vectors free to float in space until constrained to control. An error at any network node will propagate through network. 2014-05-2930GNSS Background
31
GNSS Surveys GNSS measurements of the same network are not connected to each other. GNSS measurements are independent. There are no inherent connections between project marks as in optical surveying. Computing the position of each mark relative to the same reference is optimal. Although possible, artificially creating “chains” of dependencies among project marks is not optimal. 2014-05-2931GNSS Background
32
An Appropriate Processing Strategy 24hr >2hr Hub Select a CORS to act as the local Hub creating baselines < 100 km if possible. Recall that a Hub is a mark to which baseline connections are preferentially made. All project marks are positioned relative to the Hub, not to each other. Assuming the Hub is a CORS, no data from the project marks is lost because of mutual visibility. Include a distant CORS for reliable tropo correction estimation. CORS (Hub) to CORS (distant) implies ample data with no mutual visibility issues. 2014-05-2932GNSS Background
33
GNSS Processing Principles Two principles to bear in mind: Relative Positioning – Precision o Project marks share common Hub. A Hub is a mark to which baseline connections are preferentially made. o This minimizes common-mode errors. Absolute Positioning – Accuracy o Hub(s) are adjusted into NSRS using multiple CORS. Examples given in subsequent presentations. 2014-05-2933GNSS Background
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.