rinex格式.htm

gps-RINEX的格式介绍

                  measurements using the real-time-derived receiver clock 
                  offsets dT(r), the consistency of the 3 quantities phase / 
                  pseudo-range / epoch must be maintained, i.e. the receiver 
                  clock correction should be applied to all 3 observables:</P>
                  <P>Time(corr) = Time(r) - dT(r)<BR>PR(corr) = PR(r) - 
                  dT(r)*c<BR>phase(corr) = phase(r) - dT(r)*freq</P>
                  <P>DOPPLER:</P>
                  <P>The sign of the doppler shift as additional observable is 
                  defined as usual:</P>
                  <P>Positive for approaching satellites.</P>
                  <P>4. THE EXCHANGE OF RINEX FILES:</P>
                  <P>We recommend using the following naming convention for 
                  RINEX files:</P>
                  <P>ssssdddf.yyt ssss: 4-character station name 
                  designator<BR>ddd: day of the year of first record<BR>f: file 
                  sequence number within day<BR>0: file contains all the 
                  existing<BR>data of the current day<BR>yy: year<BR>t: file 
                  type:<BR>O: Observation file<BR>N: Navigation file<BR>M: 
                  Meteorological data file<BR>G: GLONASS Navigation file</P>
                  <P>To exchange RINEX files on magnetic tapes we recommend 
                  using the following tape format:<BR>- Non-label; ASCII; fixed 
                  record length: 80 characters;<BR>block size: 8000<BR>- First 
                  file on tape contains list of files using above-mentioned 
                  naming conventions</P>
                  <P>When data transmission times or storage volumes are 
                  critical we recommend compressing the files prior to storage 
                  or transmission using the UNIX "compress" und "uncompress" 
                  programs. Compatible routines are available on VAX/VMS and 
                  PC/DOS systems, as well.</P>
                  <P>Proposed naming conventions for the compressed files:</P>
                  <P>System Obs files GPS Nav Files GLONASS Nav Files Met 
                  Files<BR>UNIX ssssdddf.yyO.Z ssssdddf.yyN.Z ssssdddf.yyG.Z 
                  ssssdddf.yyM.Z<BR>VMS ssssdddf.yyO_Z ssssdddf.yyN_Z 
                  ssssdddf.yyG_Z ssssdddf.yyN_Z<BR>DOS ssssdddf.yyY ssssdddf.yyX 
                  ssssdddf.yyV ssssdddf.yyW</P>
                  <P>5. RINEX VERSION 2 FEATURES</P>
                  <P>The following section contains features that have been 
                  introduced for RINEX Version 2.</P>
                  <P>5.1 Satellite Numbers:</P>
                  <P>Version 2 has been prepared to contain GLONASS or other 
                  satellite systems' observations. Therefore we have to be able 
                  to distinguish the satellites of the different systems: We 
                  precede the 2-digit satellite number with a system 
                  identifier.</P>
                  <P>snn&nbsp;&nbsp;s: satellite system identifier<BR>G or blank 
                  : GPS<BR>R : GLONASS<BR>T : Transit</P>
                  <P>nn :PRN (GPS), almanac number (GLONASS) or two-digit 
                  Transit satellite number</P>
                  <P>Note: G is mandatory in mixed GPS/GLONASS files</P>
                  <P>(blank default modified in April 1997)</P>
                  <P>5.2 Order of the Header Records:</P>
                  <P>As the record descriptors in columns 61-80 are mandatory, 
                  the programs reading a RINEX Version 2 header are able to 
                  decode the header records with formats according to the record 
                  descriptor, provided the records have been first read into an 
                  internal buffer.</P>
                  <P>We therefore propose to allow free ordering of the header 
                  records, with the following exceptions:</P>
                  <P>- The "RINEX VERSION / TYPE" record must be the first 
                  record in a file</P>
                  <P>- The default "WAVELENGTH FACT L1/2" record (if present) 
                  should precede all records defining wavelength factors for 
                  individual satellites</P>
                  <P>- The "# OF SATELLITES" record (if present) should be 
                  immediately followed by the corresponding number of "PRN / # 
                  OF OBS" records. (These records may be handy for documentary 
                  purposes. However, since they may only be created after having 
                  read the whole raw data file we define them to be 
optional.</P>
                  <P>5.3 Missing Items, Duration of the Validity of Values</P>
                  <P>Items that are not known at the file creation time can be 
                  set to zero or blank or the respective record may be 
                  completely omitted. Consequently items of missing header 
                  records will be set to zero or blank by the program reading 
                  RINEX files. Each value remains valid until changed by an 
                  additional header record.</P>
                  <P>5.4. Event Flag Records</P>
                  <P>The "number of satellites" also corresponds to the number 
                  of records of the same epoch followed. Therefore it may be 
                  used to skip the appropriate number of records if certain 
                  event flags are not to be evaluated in detail.</P>
                  <P>5.5 Receiver Clock Offset</P>
                  <P>A large number of users asked to optionally include a 
                  receiver-derived clock offset into the RINEX format. In order 
                  to prevent confusion and redundancy, the receiver clock offset 
                  (if present) should report the value that has been used to 
                  correct the observables according to the formulae under item 
                  1. It would then be possible to reconstruct the original 
                  observations if necessary. As the output format for the 
                  receiver-derived clock offset is limited to nanoseconds the 
                  offset should be rounded to the nearest nanosecond before it 
                  is used to correct the observables in order to guarantee 
                  correct reconstruction.</P>
                  <P>6. ADDITIONAL HINTS AND TIPS</P>
                  <P>Programs developed to read RINEX Version 1 files have to 
                  verify the version number. Version 2 files may look different 
                  (version number, END OF HEADER record, receiver and antenna 
                  serial number alphanumeric) even if they do not use any of the 
                  new features</P>
                  <P>We propose that routines to read RINEX Version 2 files 
                  automatically delete leading blanks in any CHARACTER input 
                  field. Routines creating RINEX Version 2 files should also 
                  left-justify all variables in the CHARACTER fields.</P>
                  <P>DOS, and other, files may have variable record lengths, so 
                  we recommend to first read each observation record into a 
                  80-character blank string and decode the data afterwards. In 
                  variable length records, empty data fields at the end of a 
                  record may be missing, especially in the case of the optional 
                  receiver clock offset.</P>
                  <P>7. RINEX UNDER ANTISPOOFING (AS)</P>
                  <P>Some receivers generate code delay differences between the 
                  first and second frequency using cross-correlation techniques 
                  when AS is on and may recover the phase observations on L2 in 
                  full cycles. Using the C/A code delay on L1 and the observed 
                  difference it is possible to generate a code delay observation 
                  for the second frequency.</P>
                  <P>Other receivers recover P code observations by breaking 
                  down the Y code into P and W code.</P>
                  <P>Most of these observations may suffer from an increased 
                  noise level. In order to enable the postprocessing programs to 
                  take special actions, such AS-infected observations are 
                  flagged using bit number 2 of the Loss of Lock Indicators 
                  (i.e. their current values are increased by 4).</P>
                  <P>8. GLONASS Extensions</P>
                  <P>8.1 RINEX Observation file</P>
                  <P>8.1.1 Time System Identifier</P>
                  <P>RINEX Version 2 needs one major supplement, the explicit 
                  definition of the time system:</P>
                  <P>GLONASS is basically running on UTC (or, more precisely, 
                  GLONASS system time linked to UTC(SU)), i.e. the time tags are 
                  given in UTC and not GPS time. In order to remove possible 
                  misunderstandings and ambiguities, the header records "TIME OF 
                  FIRST OBS" and (if present) "TIME OF LAST OBS" in GLONASS and 
                  GPS observation files _can_, in mixed GLONASS/GPS observation 
                  files _must_contain a time system identifier defining the 
                  system that all time tags in the file are referring to: "GPS" 
                  to identify GPS time, "GLO" to identify the GLONASS UTC time 
                  system. Pure GPS files default to GPS and pure GLONASS files 
                  default to GLO.</P>
                  <P>Format definitions see Table A1.</P>
                  <P>Hence, the two possible time tags differ by the current 
                  number of leap seconds.</P>
                  <P>In order to have the current number of leap seconds 
                  available we recommend to include a LEAP SECOND line into the 
                  RINEX header.</P>
                  <P>If there are known non-integer biases between the "GPS 
                  receiver clock" and "GLONASS receiver clock" in the same 
                  receiver, they should be applied.</P>
                  <P>In this case the respective code and phase observations 
                  have to be corrected,too (c * bias if expressed in 
meters).</P>
                  <P>Unknown such biases will have to be solved for during the 
                  post processing</P>
                  <P>The small differences (modulo 1 second) between GLONASS 
                  system time, UTC(SU),UTC(USNO) and GPS system time have to be 
                  dealt with during the post-processing and not before the RINEX 
                  conversion. It may also be necessary to solve for remaining 
                  differences during the post-processing.</P>
                  <P>8.1.2 Pseudorange Definition</P>
                  <P>The pseudorange (code) measurement is defined to be 
                  equivalent to the difference of the time of reception 
                  (expressed in the time frame of the receiver) and the time of 
                  transmission (expressed in the time frame of the satellite) of 
                  a distinct satellite signal.</P>
                  <P>If a mixed-mode GPS/GLONASS receiver refers all pseudorange 
                  observations to one receiver clock only,</P>
                  <P>- the raw GLONASS pseudoranges will show the current number 
                  of leap seconds between GPS time and GLONASS time if the 
                  receiver clock is running in the GPS time frame</P>
                  <P>- the raw GPS pseudoranges will show the negative number of 
                  leap seconds between GPS time and GLONASS time if the receiver 
                  clock is running in the GLONASS time frame</P>
                  <P>In order to avoid misunderstandings and to keep the code 
                  observations within the format fields, the pseudoranges must 
                  be corrected in this case as follows:</P>
                  <P>PR(GPS) := PR(GPS) + c * leap_seconds if generated with a 
                  receiver clock running in the GLONASS time frame</P>
                  <P>PR(GLO) := PR(GLO) - c * leap_seconds if generated with a 
                  receiver clock running in the GPS time frame</P>
                  <P>to remove the contributions of the leap seconds from the 
                  pseudoranges.</P>
                  <P>"leap_seconds" is the actual number of leap seconds between 
                  GPS and GLONASS(UTC) time, as broadcast in the GPS almanac and 
                  distributed in Circular T of BIPM.</P>
                  <P>8.1.3 More than 12 satellites per epoch</P>