# Presentation: 300833

## The RINEX format:Current status, future developments

**Werner Gurtner**

## Current Status

**Version 2.11 currently used by the geodetic community**** **
**Version 3.00 used as official exchange format by the Galileo-related institutions (e.g., GGSP)**** **
**Version 2.20 was developed for the IGS LEO project, contains some additional features for the tracking of GPS-equipped LEO satellites:**
**MARKER TYPE**
**CENTER OF MASS in body-fixed coordinates**
**ANTENNA: Position in body-fixed coordinates, boresight**
**OBS SCALE FACTOR**
**Special code for L1(C/A): "LA"**

## Identified Problems: Version 2.11

**Observation codes cannot distinguish between L2(P) and L2(L2C)**** **
**Problem because of 1⁄4-cycle phase shift of L2(L2C) w/r to L2(P)**** **
**If L2C- and P-code derived L2 phases are combined in an analysis, ambiguity-resolution can be jeopardized, if these phase shifts are not taken into account**
**Need some agreement for 2.11 how to handle this**

## 1⁄4-cycle phase shift of L2(L2C) w/r to L2(P)

Possible phase shifts of phases based on the various tracking modes of modern signals
I channel (pilot channel)
Q channel (data channel) 
Combination of the two
E5a, E5b, combination of the two
BOC versus MBOC on the same frequency (E1)

Need additional code for MBOC-tracked E1
Many receivers will continue to track BOC
High-end receivers might track MBOC (more complex, but better performance)

**Possible phase shifts of phases based on the various tracking modes of modern signals**
**I channel (pilot channel)**
**Q channel (data channel) **
**Combination of the two**
**E5a, E5b, combination of the two**
**BOC versus MBOC on the same frequency (E1)**
**Need additional code for MBOC-tracked E1**
**Many receivers will continue to track BOC**
**High-end receivers might track MBOC (more complex, but better performance)**

**Identified Problems: Version 3.0**

## Controversial Discussion

**Should all phases be shifted to a common reference, if necessary, before generating RINEX files?****	****	****	****	****or**
**Should all phase observations be stored in the "original" state and leave the task to do the necessary corrections to the user?**
**E-Mail discussion in "RINEX group" (distribution list of ~45 addresses):**
**	**_**[http](http://www.aiub.unibe.ch/download/rinex/L2C/)**__**[://www.aiub.unibe.ch/download/rinex/L2C/](http://www.aiub.unibe.ch/download/rinex/L2C/)**_** **

## Phase corrections: Pros

**The receiver knows what it is doing, i.e. it knows its tracking mode.******** It can do the corrections to an accepted standard**** **
**The manufacturer-provided RINEX converter knows what the receiver did store in the proprietory format: The converter can do the corrections**** **
**The user does not have to deal with these corrections. He can freely mix observables without having to bother with corrections.**
**No changes to many existing programs**
**Keep things simple for the user. Modern GNSS signals will be complicated enough to deal with**
**If the receiver just stores what comes out of its tracking loops: Is it sure that this phase really follows the general assumptions?**

## Phase corrections: Cons

**RINEX philosophy till now: No "external" corrections to the data**
**Are we sure that the corrections have been applied correctly? Or applied at all?**
**How to apply a priori corrections if the RINEX converter does not know the tracking mode or the signal-generation mode of the satellite ("flex power")?**
****** ****Same problem, of course, holds for the users!**
**Flex power will not generate phase shifts (statement in recent presentation in Los Angeles)**
**Who is setting the standards?**
**What happens with the existing data?**

## Phase corrections: Current status

**Trimble:**
**Shifts L2(L2C) by 1⁄4 cycle**
**Correction procedure for all currently tracked signals available**
**Leica/Novatel**
**Probably no corrections to L2C for the time being**
**Septentrio**
**Currently no corrections for RINEX 3.0**
**Proposes to correct to standard**
**RTCM: Discussions under way. Probably going for a standard**
**Geo++**
**Proposes to store unchanged phases into RINEX**

## Some Facts

**No corrections are necessary for a specific receiver/station if only one tracking mode per frequency for all satellites**
**It's not important if all phases observed by a receiver in mode A are aligned to mode B or if all phases of mode B are aligned to mode A**
**Double-difference processing (ambiguity resolution OK)**
**Zero-difference processing (ambiguity resolution OK, if possible...)**
**PPP**
**If one decides to apply corrections, do them**
**either to a commonly accepted, general standard**
**or to a "*****receiver-internal standard*****" in case of mixed modes**

## Decision

**Should be taken by the RINEX group in the very next future**
**Comments to **_**[gurtner@aiub.unibe.ch](mailto:gurtner@aiub.unibe.ch)**_
**Hopefully in agreement with RTCM**

## Future of RINEX

**Currently: Discussions and decisions mainly in the RINEX group, often driven by requests and experiences by IGS**
**Do we need a formal "RINEX body"?**

## Discussions in IGS

**Transition from Version 2.11 to Version 3.0**
**Yes or no**
**If yes:**
**When?**
**How to organize?**
**Are there converters around?**
**Dependence on teqc: 90 percent of all IGS RINEX files generated by teqc**** **
**If no:**
**Stick to 2.11? Improve 2.11?**
**Transition to something else?**
**How to deal with Galileo and modern GPS signals?**