inputtip.txt

这是国外关于卫星导航方面一书的源代码

-------------------------------------------------------------------------------
GPSLab  -  RIN2MAT conversion of RINEX files in MatLab readable files
-------------------------------------------------------------------------------

Attention
=========

With "start RINEX Import" the program RIN2MAT.M is called.
The specified RINEX files are read and from the data the following new
ASCII files are built:

Reference station:    s1head  s1epo  s1c1  s1p1  s1p2  s1l1  s1l2  s1log  s1eph
Rover station:        s2head  s2epo  s2c1  s2p1  s2p2  s2l1  s2l2  s2log  s2eph

1. RINEX files have to fulfill the requirements of the 
   official data format RINEX Version 2.
   (Author: W. Gurtner, Version 2.10, Revision/Clarification Status: Dec 1999)
   They have to be in ASCII format, no "UNIX-compressed Files", 
                                    no "Compact RINEX" (Hatanaka) !
   For detailed spezification see the file "RINEX2.TXT"
   Some remarks relating the RINEX2 convention you can find in "Remarks" below.

   Attention: The program is prepaired for version 2.10 of RINEX.
              This resulted in some source code changes of the conversion programs; 
              I hope that I considered all eventualities.

2. The file name extensions have to be *.yyO (observation files) and
                                       *,yyN (navigation files),
   where yy stands for the year of observation date.

3. Error messages while conversion are documented in the Log files s1log bzw. s2log .
   Following standard error messages are possible:

   *** Kein RINEX2-N-File; Fehler[1] i.d. 1.Zeile *** 
   => it means, that there exists a problem due to format (80 characters per row: o.k.?)

   *** Kein RINEX2-N-File; Fehler[2] i.d. 1.Zeile ***
   => it means, that the RINEX version number does not exist or is not equal 2.
   In the first case you can correct that simply by editing the RINEX file; for that
   purpose see the file RINEX2.TXT. But in the second case you have a problem:
   RINEX version 1 N-Files cannot be used; and they cannot be converted into RINEX 2
   by a simple editing procedure !

   *** Fehler [3]: RINEX2-N Format-Konvention verletzt:       ***
   *** Data Record Zeilenlaenge groesser als 79 Zeichen (!)   ***
   *** beim Versuch, den   xxx -ten Satellitenblock zu lesen  ***
   => it means, that the RINEX format is not strictly fulfilled: too many columns.
   The errror appears at the xxx-th set of the clock / orbit parameters.


Remarks (RINEX2 convention):
----------------------------
-   The antennen height is the height ofthe antenna bottom plane above the marker
    (IGS definition "ARP")
-   The epoch relates to the carrier and code phase observations of all satellites
-   Pseudoranges contain both clock errors (satellite and receiver)
-   Carrier phase observations are in full cycles, the possibility of 
    half cycle ambiuities and slips are indicated in the header.
-   phase observations are not corrected for atmospheric refraction
    or for satellite clock errors and so on ...
-   If the receiver clock error is printed, it should be applied to the 
    carrier and code phase observations and to the epoch:
    Time(corr)  = Time(r)  - dT(r)
    PR(corr)    = PR(r)    - dT(r) * c
    phase(corr) = phase(r) - dT(r) * freq
    E.g. LEICA receivers correct it (OBSTORNX Version 1.09).
-   Already known RINEX2 conventions violations:
  -  Rogue-RINEX: 2 instead of 4 character year declaration in "TIME OF FIRST OBS" record
  -  GPS-Edit-RINEX (standalone version before GeoGenius released): 
     Broadcast orbit blocks are in the format 2X4D20.xx instead of 3X4D19.12
  -  GeoGenius: Converting some old GeoGPS- or Geotracer2102-OBS-files there will
     inserted a set of erroneous characters into the MARKER row of the header
-   millisecond (ms) steps:
    Receiver with clocks that drift away from GPS time scale more than one ms
    are corrected by addition or subtraction of one ms. Either the
    epoch value in the RINEX file is changed by one second or the epoch
    is set to integer nominal epochs (e.g. seconds) and a step of 299792.458 m 
    is inserted into the pseudoranges; 
    in both cases the carrier phases are not touched by such a step.
    Both cases are considered in this program. Violations of this 
    RINEX convention are not allowed!


Remarks on the GPS Week Rollover 1999 and on the Y2K problem:
-------------------------------------------------------------
The GPS week rollover problem does not appear here, unless the value for the 
GPS week in the RINEX N file is not counted correctly: 
Since 1999-08-22 the GPS week 0 started again (following the week 1023). 
But this is handled in such a way only by the GPS system provider
because of too little space in the Broadcast Message Frame. In the 
RINEX files the week number is continued (per definitionem).

The Y2K problem does not appear, because the date in year 00 an the following
is converted correctly in GPS week and week second 
(appears in RINEX N and O files).

Obligatory in the RINEX2 files:

RINEX-O-file: No appearance of GPS week
              year displayed by 4 characters in the header, 
                             by 2 characters in every epoch 

RINEX-N-file: GPS week displayed for Time of Ephemeris (toe) (each satell. set)
              year displayed by 2 characters in Time of Clock (toc) 
                                                             (each satell. set)

-------------------------------------------------------------------------------
(c) iapg 1997/1998/1999 zeb
-------------------------------------------------------------------------------