# Presentation: 181182

## Case study for the IGS ultra-rapid orbit requirements

_**Case study for the IGS ultra-rapid **__**orbit requirements**_

***Jan Douša***
***Miami****** Beach******, June 2-6, 2008***

**Notes:**
Ěéč;í

## Outline

**quality of IGS ultra-rapid orbit prediction**
**effect of ephemeris errors on ZTD (PPP case)**
**effect in network solution**
**simulation in network analysis**
**summary**

- Miami Beach, June 2-6, 2008

## Monitoring the quality of IGU orbits

- IGU w.r.t IGR orbits
- comparison in terrestrial system after Helmert transformation
- 3 Helmert rotations estimated epoch by epoch (15min) for relevant satellites only
- fitted portion compared in 0-24 hours
- predicted portion compared on hourly basis (1,2,3,4,.., 23)
- monthly orbit prediction statistics evaluated
- accuracy code validated with IGU x IGR orbit differences
- the orbit quality and the accuracy codes validated separately

- Miami Beach, June 2-6, 2008

## 2004-2008 time-series of IGU orbit predictions

- Miami Beach, June 2-6, 2008

## Eclipsing periods

- per year every satellite
- undergoes eclipsing
- period
- (in yellow)

_**Eclipsing periods**_

- plots generated from the IGS ACC’s IGUxIGR comparison summary tables

- Miami Beach, June 2-6, 2008

## Orbit quality dependance on the prediction

_**Orbit quality dependance on the **__**predictio**__**n**_

**orbit accuracy with respect to the prediction interval  **
- (monthly statistics)

- GPS Block IIR-M

- GPS Block IIA

- GPS Block IIA

- Miami Beach, June 2-6, 2008

## Accuracy code validation (6h prediction)

- Miami Beach, June 2-6, 2008

## Effect of ephemeris errors on PPP ZTD

- Basic GPS carrier phase observable (scaled to distance):
- Lrecsat = recsat +  c.sat + c.rec + .nrecsat + ION + TRP   + recsat
- recsat  .. receiver-satellite distance in vacuum
- TRP      .. troposphere path delay we approximate as 1/cos(z) * ZTD
- The ephemeris error is projected into the observables via a unit vector directing from receiver to satellite:
**   **_**R**_recsat  / |_**R**_recsat| ****_**X**_sat**  **** **=  _**e**_ recsat ****_**X**_sat
**	**** ****	****                  **** **=  _**e**_ recsat Rz (sat) Rz (sat) . ****_**X**_RACsat
- We are interested in Radial/Along-track/Cross-track component errors, but we distinct only Radial and Tangential (Along-track + Cross-track) components and we do not need to consider the satellite track direction.
- Generalizing the situation to be independent of the receiver/satellite positions, we express the errors as zenith dependent only:
-  _**e**_ recsat . Rz (sat) Rz (sat) . ****_**X**_RAC** **sat = cos() XRadsat + sin() XTansat
- where   = arcsin(sin(z) . Rrec/Rsat)
- 	is a paralax for the satellite between the geocenter and the station.
- Putting equal the projected orbit errors with troposphere model we get an impact

- Miami Beach, June 2-6, 2008

## Orbit errors in PPP ZTD

_**Orbit errors **__**in PPP ZTD**_

**Assumption: **
**orbit errors only ZTD**
**(usually also in ambiguities, clocks)**

- _Radial error_
- impact=1.0 in zenith
- impact=0.0 in horizon
- _Tangential error_
- depends on track orientation
- max impact=0.13    (45deg)
- min impact=0.00    (0-90deg)

_**Point positioning**_

- Miami Beach, June 2-6, 2008

## Effect in network solution

- In network double-difference observables are used:
- Lklij = Lkli – Lklj   = ( Lki – Lli  ) – ( Lkj – L lj )
- but for single satellite error we can consider only single difference for baseline, relevant portion of the observation equation is:
- Lkli **= **|_**R**_ ki|**-**|_**R**_ li|**  + (**_**e**_ ki – _**e**_ li **) ******_**X**_ i** **+ cos(zki) ZTD k - cos(zli) ZTD l   **+ ...**
- Again, we distinguish the Radial and Tangential error only and we project them into the receiver-satellite distance as zenith (or paralax, ) dependant function:
-  **(**_**e**_ ki – _**e**_ li **)** Rz (i) Rz (i) . ****_**X**_RACi   =    ( cos(ki) ****XRadi  + sin(ki) ****XTani   )
-                                                        – ( cos( li) ****XRadi + sin( li) ****XTani  )
- but we need the coordinates for estimating the zenith angle at the second station.
- Studying the two marginal cases we can keep a general description limited only by defining the baseline lenght 1000 km:
_**equal azimuths**_ –satellite and second station are in equal azimuths
_**equal zeniths**_ – zeniths to satellite are equal for both stations
- We calculate the impact in ZTD if the error is not absorbed by other parameters.

- Miami Beach, June 2-6, 2008

## Radial orbit error in DD ZTD

**Assumption: ****(1000km)**
**orbit errors only ZTD**
**(usually also by ****	****ambiguities)**** **

_**Radial orbit error in DD ZTD**_

- _Radial error_
- impact=0.0 cancelled in case of equal zeniths
- max impact = 0.0023 (38deg) in case of equal azimuths
-      min impact->0.0 above the baseline or close to horizon

_**Network solution**_

- Miami Beach, June 2-6, 2008

## Tangential orbit error in DD ZTD

- _Tangential error_
- depends on satellite track orientation with respect to baseline
- max impact = 0.027 is above the mid of baseline for both cases and orbit error ‘paralalel’ to baseline
- impact reduced always when error is ‘perpendicular’ to baseline
- impact reduced with decreasing elevation (slightly different for both cases)

_**Network solution**_

- Miami Beach, June 2-6, 2008

## Simulation in network analysis

_**Network:**_
- - 16 sites approx. 1000km distances
- - ‘star’ baselines strategy from central point
_**Solution:**_
- - synthetic (constant) errors (1,5,10,25,100cm) introduced in the orbits consequently in radial, along-track and cross-track component for selected satellite
- - pre-processing of 24h data with the original IGS final orbits
- - ZTD estimated with original IGS final orbits (reference ZTD)
- - ZTD estimated with biased orbits (tested ZTD)
- - ZTD estimated with ambiguities free (estimated simultaneously)
- - ZTD estimated with ambiguities fixed (using original IGS orbits)
- comparison of resulted ZTDs

- Miami Beach, June 2-6, 2008

## Effects of the synthetic orbit errors in ZTD

_**Effects of the synthetic orbit errors in ZTD**_

- Miami Beach, June 2-6, 2008

## Effect of the synthetic orbit errors in ZTD (2)

_**Effect of the synthetic orbit errors in ZTD (2)**_

- _Ambiguity fixed_

- _Ambiguity free_

- Miami Beach, June 2-6, 2008

## Orbit requirements – particular example

**Note:** solving for the ambiguities significantly helps to overcome the limits in  quality of the predicted orbits (and predicted accuracy codes)
_**network solution**_
- baselines 1000 km            (ZTD bias reduces to half if 500km)
- max 1cm error in ZTD
**requirements:** _**217cm in radial and 19cm in tangential **__**direction**_
_**PPP solution**_
- max 1cm error in ZTD
**requirements:** _**1cm in radial and 7cm in tangential **__**direction**_
_**currently IGU prediction quality observed:**_
- prediction length: 1-9h for NRT/RT
- nominal situation:               1cm  |  3-5cm  |  2-3cm     [R|A|O rms]
- during eclipsing period:   1-3cm | 4-20cm  |  3-8cm     [R|A|O rms]

- Miami Beach, June 2-6, 2008

## Summary – requirements for ZTD

_**network solution (ZTD)**_ is negligibly sensitive to the radial error, but along (cross)-track errors can occasionally affects the ZTDs. The baseline configuration plays a crucial role during such period - only specific baselines are sensitive in specific situation and unfortunatelly the averaging with respect to other satellite observables is limited.
_**PPP solution (ZTD)**_ depends on the accuracy of radial component (100% in zenith) in nominal situation, but on the along(cross)-track component for eclipsing Block-IIA satellites. Fortunatelly, error averaging performs over all the satellites. Satellite clocks (especially in regional solution) can absorb significant portion of the radial error.
_**the ambiguities**_ are in both cases able to absorb a significant portion of the orbit errors and currently help to reduce the effect.
- only a few weakly predicted satellites occur in a single product, thus usually a _**robust satellite checking (and excluding) strategy**_ applied by the user should be satisfactory in many cases for the network solution, although as much as satellites is generally requested.

- Miami Beach, June 2-6, 2008

## Summary – quality of IGU prediction

- after decommission of satellite G29 (October, 2008) there is no more significant difference in the standard orbit prediction performance.
- different pattern of the prediction can be seen during the eclipsing periods. We have to distinguish between satellites of old **Block-IIA **(fastly degrading) and new **Block-IIR **(modestly degrading) types.
- there are still 14 [15] of** old-type **satellites **active (45%):** G01, G03, G04, G05, G06, G08, G09, G10, G24, G25, G26, G27, G30, [G32].
- accuracy codes are in most cases relevant for the prediction, but usually **underestimated for Block-IIA during eclipsing** periods and at **the start of the maintenance periods**.
- currently 1-9h prediction are at least necessary for NRT/RT usage
- shorter prediction will be appreciated especially due to old Block-IIA satellites, but mainly for the NRT/RT (global) PPP applications.
_**Relevant question to AC’s:**_ how simply they can provide the orbits upgraded every 3h (+2h delay ?) with the same quality as of today ?
- (Even higher update rate could be requested for the PPP solutions).

- Miami Beach, June 2-6, 2008