Rinex格式说明
rinex 3.03格式说明
RINEX Version 3.03 ii
5.7 Signal strength .................................................................................................................................. 22 Table 12: Standardized S/N Indicators ............................................................................................... 22 5.8 Date/time format in the PGM / RUN BY / DATE header record ..................................................... 22 5.9 Antenna phase center header record ................................................................................................. 23 5.10 Antenna orientation ......................................................................................................................... 23 5.11 Observation data records................................................................................................................. 23 Table 13: Example Observation Type Records .................................................................................. 23 Table 14: Example Observation Data Records ................................................................................... 23 5.12 Ionosphere delay as pseudo-observables ........................................................................................ 24 Table 15: Ionosphere Pseudo-Observable Coding .............................................................................. 24 Table 16: Ionosphere Pseudo-Observable Corrections to Observations ............................................. 24 5.13 Channel numbers as pseudo-observables ........................................................................................ 24 5.14 Corrections of differential code biases (DCBs) .............................................................................. 25 5.15 Corrections of antenna phase center variations (PCVs) .................................................................. 25 5.16 Navigation message files ................................................................................................................ 25 Table 17: Example of Navigation File Satellite System and Number Definition Record .................. 25 Table 18: Example of Navigation File Header IONOSPHERIC CORR Record ................................ 25 6. ADDITIONAL HINTS AND TIPS ........................................................................................................ 26 6.1 Versions ............................................................................................................................................ 26 6.2 Leading blanks in CHARACTER fields ........................................................................................... 26 6.3 Variable-length records ..................................................................................................................... 26 6.4 Blank fields ....................................................................................................................................... 26 6.5 Order of the header records, order of data records............................................................................ 26 6.6 Missing items, duration of the validity of values .............................................................................. 27 6.7 Unknown / Undefined observation types and header records ........................................................... 27 6.8 Event flag records ............................................................................................................................. 27 6.9 Receiver clock offset......................................................................................................................... 27 6.10 Two-digit years ............................................................................................................................... 27 6.11 Fit interval (GPS navigation message file) ..................................................................................... 28 6.12 Satellite health (GPS navigation message file) ............................................................................... 28 Table 19: Description of GPS Satellite Health Field .......................................................................... 28 6.13 Transmission time of message (GPS navigation message file)..........................................5
Rinex
RinexRINEX（Receiver INdependent Exchange）格式是与接收机无关的数据交换格式，该格式采用文本文件存储数据，数据记录格式与接收机的制造厂商和具体型号无关。
RINEX格式由瑞士伯尔尼大学天文学院（Astronomical Institute, University of Berne）的Werner Gurtner于1989年提出。
当时提出该数据格式的目的是为了能够综合处理在EUREF89(欧洲一项大规模的GPS联测项目)中所采集的GPS数据。
该项目采用了来自4个不同厂商共60多台GPS接收机。
现在，RINEX格式已经成为了GPS测量应用等的标准数据格式，几乎所有测量型GPS接收机厂商都提供将其格式文件转换为RINEX格式文件的工具，而且几乎所有的数据分析处理软件都能够直接读取RINEX格式的数据。
这意味着在实际观测作业中可以采用不同厂商、不同型号的接收机进行混合编队，而数据处理则可采用某一特定软件进行。
Rinex格式文件包括6种文件类型：观测数据文件：GPS观测值导航电文文件：GPS卫星导航电文气象数据文件：在测站处所测定的气象数据GLONASS导航电文文件：GLONASS卫星导航电文GEO导航电文文件：增强系统中搭载有类GPS信号发生器的地球同步卫星（GEO）的导航电文卫星和接收机钟文件：包含卫星和接收机时钟信息其中用的最多的是O文件、N文件和M文件，观测值文件的文件头存放有文件的创建日期、单位名、测站名、天线信息、测站近似坐标、观测值数量及类型、观测历元间隔等信息。
导航电文的文件头存放有文件创建日期、单位名及其他一些相关信息, 另外, 还有可能会包含电离层模型的参数以及说明GPS时与UTC 间关系的参数和跳秒等。
气象数据文件的文件头则存放有文件创建日期、观测值类型、传感器信息和气象传感器的近似位置及其他一些相关信息。
RINEX 格式文件的记录数据紧跟在文件头的后面, 随文件类型的不同, 所存放数据的内容和具体格式也不相同。
rinex 星历格式
rinex 星历格式RINEX（Receiver Independent Exchange）星历格式是一种用于交换和共享GNSS（全球导航卫星系统）星历数据的国际标准。
该格式规定了一套统一的数据结构和存储方式，使得不同厂家的GNSS接收机可以互相交换星历数据，从而实现数据的通用性和互操作性。
RINEX星历格式的主要特点如下：1. 文件格式简洁明了：RINEX星历文件是以文本格式存储的，采用ASCII码编码，易于阅读和处理。
该格式采用了简单的行结构，每行包含特定的数据类型和字段，严格按照规定的顺序排列，方便解析和提取数据。
2. 可兼容不同系统和频率：RINEX星历格式广泛支持多种GNSS系统（如GPS、GLONASS、Galileo等）和频率（如L1、L2等）。
它允许将不同系统和频率的星历数据合并到同一个文件中，便于用户进行综合分析和处理。
3. 精确的时间标识：RINEX星历文件中的每条记录都有精确的时间标识，可用于数据对齐和时间同步。
它使用GPS周内秒（GPS Week and Seconds of Week, WSOW）来表示时间，具有较高的时间分辨率和精度。
4. 多种数据类型支持：RINEX星历格式不仅可以存储星历数据，还支持其他相关的辅助数据类型，如观测值、钟差、观测站信息等。
用户可以根据自己的需求选择存储的数据类型，使得文件具有更大的灵活性和扩展性。
5. 格式版本兼容性：RINEX星历格式定义了多个版本，用户可根据需要选择适合自己的版本。
格式版本之间兼容性良好，较新版本通常包含了更多的数据类型和字段，支持更高级的功能和算法。
同时，旧版本的数据也可以经过适当的转换和升级，兼容使用较新版本的软件和工具。
总之，RINEX星历格式是一种非常重要的数据交换和共享标准，它在GNSS领域发挥着重要的作用。
通过使用RINEX格式，用户可以轻松地处理和分析来自不同厂家和系统的星历数据，为科研、应用开发和工程设计提供了便利和灵活性。
Rinex格式说明
I3,
12(A1,I2),
F12.9
32X,
12(A1,I2)
[2X,I1,]
[I3]
OBSERVATIONS
-观测值
- LLI
-信强度
如果超过5种观测类型（80字节）：下行继续
同一历元中的所有卫星，对应一条记录
观测值:
相位:单位周
相位:单位米
如果没有观测则记录0或记录为空
相位观测值溢出F14.3，必须进行截断,用LLI表明.
I2,
1X,I2.2,
1X,I2,
1X,I2,
1X,I2,
1X,I2,
F5.1,
3D19.12
BROADCAST ORBIT - 1
- IODE数据分发历书
- Crs (米)
- Delta n (弧度/秒)
- M0 (弧度)
3X,4D19.12
BROADCAST ORBIT - 2
- Cuc (弧度)
标签
第61-80列，从零开始计数
描述
格式
RINEX VERSION / TYPE
-版本(2.10)
-文件类型('N'表示导航文件)
F9.2,11X,
A1,19X
PGM / RUN BY / DATE
-创建当前文件的程序名称
-创建当前文件的机构名称
-创建文件的时间
A20,
A20,
A20
*COMMENT
I6
*WAVELENGTH FACT L1/2
- L1和L2载波的缺省系数
1:整周
2:半周
0 (L2载波):单频接收机
-系数适用的卫星数据
rinex 星历格式 -回复
rinex 星历格式-回复什么是rinex星历格式？RINEX（Receiver Independent Exchange）星历格式是一种用于交换卫星导航系统接收机的观测数据和导航数据的标准格式。
它的发展旨在解决不同厂商、不同型号之间的数据兼容性问题，使得用户可以使用不同品牌和型号的接收机进行数据交换和处理。
rinex星历格式主要用于全球卫星定位系统（GNSS）如GPS（全球定位系统）、GLONASS（格洛纳斯）、Galileo（伽利略)等，以及其它一些天文导航系统。
为什么需要rinex星历格式？在卫星导航系统中，卫星发射导航信息，接收机接收并处理这些信息以计算位置和时间。
为了获得尽可能准确的位置和时间计算结果，接收机需要准确的星历数据。
然而，不同厂商和型号的接收机生成的原始数据格式可能不同，这就给数据的交换和处理带来了困难。
rinex星历格式的出现就是为了解决这一问题，它提供了一种通用的数据格式，可以用于不同接收机之间的数据交换。
rinex星历格式的具体内容是什么？rinex星历格式主要包括了两部分：观测数据和导航数据。
观测数据包括接收机接收到的信号强度、相位测量等相关信息，导航数据包括卫星的位置、钟差等导航参数。
这些数据以文本格式存储，可以使用文本编辑器进行查看和编辑。
rinex星历格式中数据的存储方式是怎样的？rinex星历格式的数据存储方式主要有两种：压缩和非压缩。
压缩方式通过对数据进行压缩来减小文件的大小，非压缩方式则直接以文本形式存储数据。
压缩方式可以减少存储和传输的空间和时间，但需要在数据使用前进行解压处理。
非压缩方式则可以直接打开查看和编辑，不需要解压处理。
如何使用rinex星历格式进行数据交换和处理？使用rinex星历格式进行数据交换和处理包括以下几个步骤：1. 收集观测数据：首先，使用接收机接收卫星导航系统的信号，收集观测数据。
观测数据可以包括单点定位、差分定位等不同类型的数据。
华测接收机修改点名天线高和RNIEX格式简易说明
华测接收机修改点名天线高和RNIEX格式简易说明
一安装华测CGO静态处理软件；
二通过数据线连接华测接收机，然后把华测接收机打开，电脑会自动安装USB驱动，接收机的内存会以U盘形式在电脑端显示；
三把静态文件复制到电脑上；
四点击“开始”→”程序”→“huacenav”→”GHC Geomatics office”→”工具→”HCN Data Manager”;
五在被修改的HCN文件中选择观测的华测格式静态文件→修改点名（最好是四个字符）→天线类型（选择接收机型号）→天线高测量到（使用三脚架作业，一般量取到接收机护圈，选择天线斜高）→点击保存；
六打开RINEX Converter软件→转换→天线高设置→输入天线高测量方法和天线类型（如果是改正到天线相位中心，需要打钩）→确定；
七点击工具图标→卫星系统中只保留GPS；
八点击“转换”→“导入”→选择改好点名的静态文件→点击
（即把华测HCN格式静态文件转换成RNIEX通用格式）；
九打开华测CGO静态处理软件，导入RNIEX格式静态文件，会发现高度已经修改到相位中心。
rinex 星历格式 -回复
rinex 星历格式-回复rinex星历格式是一种广泛用于天文导航和定位系统的数据格式。
它是由国际电信联盟（ITU）和国际电气与电子工程师协会（IEEE）共同制定的，用于记录和交换卫星导航系统（如GPS、GLONASS和Galileo）的星历数据。
本文将一步一步回答关于rinex星历格式的问题，包括其背景、格式解释和应用领域。
第一步：背景介绍首先，我们将讨论rinex星历格式的背景和由来。
rinex（Receiver Independent Exchange）星历格式最初是为了解决卫星导航系统接收机和数据分析软件之间的兼容性问题而开发的。
在卫星导航系统的发展过程中，不同的厂商和软件开发者开发了许多不同的数据格式，这导致了数据的互操作性问题。
为了解决这个问题，ITU和IEEE制定了rinex星历格式作为一种统一的数据交换格式。
第二步：格式解释rinex星历格式通常以文件扩展名“.yyo”或“.yyd”的形式存储。
这里的“yy”是指星历文件所涉及的年份，而“o”和“d”分别表示观测星历文件和导航星历文件。
rinex星历格式的具体内容包括以下几个方面：1. RINEX版本：星历文件的版本号，例如2.10或3.03。
2. 文件头部：包含了一些元数据，如观测站的位置和测量仪器的相关信息。
3. 历元：星历数据按照时间划分为多个历元，每个历元包含了一组卫星的位置和钟差等数据。
4. 卫星编号：每个卫星都有一个唯一的编号，例如GPS系统中的PRN号。
5. 位置数据：卫星的位置数据通常以ECEF坐标系（地心地固坐标系）表示，包括X、Y和Z分量的坐标。
6. 速度数据：卫星的速度数据可以用于定位和导航计算，通常以每小时的相对速度表示。
7. 钟差数据：卫星的钟差数据指的是卫星钟与系统时间之间的偏差，用于纠正接收机的观测数据。
第三步：应用领域rinex星历格式在众多的应用领域中发挥着重要的作用。
以下是一些典型的应用领域：1. 天文导航和定位系统：rinex星历格式是实现精确导航和定位的关键。
rinex 星历格式 -回复
rinex 星历格式-回复"rinex星历格式"的技术规范和应用引言：星历数据在全球导航卫星系统（GNSS）中起着至关重要的作用。
作为GNSS接收器精确定位的基础，星历数据提供了卫星位置和卫星钟差信息，对于定位和导航精度至关重要。
rinex（Receiver Independent Exchange Format）是一种用于存储和交换卫星导航系统数据的国际标准格式。
本文将介绍rinex星历格式的结构和应用。
一、rinex星历格式的结构rinex星历格式是通过存储卫星位置和钟差的高度系统化数据文件来描述卫星的运行状态。
星历文件通常用于离线处理和后续分析。
rinex星历格式包含以下主要部分：1. 头文件（Header）头文件包含了星历数据文件的描述性信息。
该部分提供了有关文件的基本信息，如数据采集时间、GNSS系统类型、接收机和天线类型等。
此外，头文件中还包含了卫星导航定位算法所需的其他参数，如钟差滤波器参数等。
2. 导航字段rinex星历格式的导航字段部分用于存储卫星位置和钟差信息。
各项导航数据按照一定的格式和顺序存储，以便后续处理和分析。
其中，最重要的导航数据是卫星的运动模型参数、卫星位置和钟差信息。
3. 文件结束标记星历文件以文件结束标记结尾，这个标记用于确定文件的结尾，以便后续软件处理。
二、rinex星历格式的应用rinex星历格式广泛应用于卫星导航系统数据的存储、分析和处理。
以下是rinex星历格式的主要应用：1. GNSS接收器的基准站数据处理基准站是GNSS网络中非常重要的组成部分，用于提供高精度、连续可靠的参考数据。
rinex星历格式可以帮助基准站用户将观测数据与星历数据进行配准和联合计算，从而实现高精度的测量和定位。
2. GNSS定位和导航算法开发对于GNSS定位和导航算法的研究和开发工作，rinex星历格式是不可或缺的工具。
研究人员可以利用rinex星历格式提供的数据，构建相应的算法模型，实现卫星位置和钟差的精确定位和导航。
RINEX格式
RINEX格式RINEX是The Receiver Independent Exchange Format（与接收机无关的数据交换格式）的缩写，它是GPS测量领域中的一种广为使用的数据格式，绝大部分的数据处理软件均支持这种格式。
下面是一份有关该格式的文挡：RINEX: The Receiver Independent Exchange Format Version 2*********************************************************(Revision, April 1993)(Clarification December 1993)(Doppler Definition: January 1994)(PR Clarification: October 1994)(Wlfact Clarification: February 1995)(Event Time Frame Clarification: May 1996)(Minor errors in the examples A7/A8: May 1996)(Naming convention for compressed met files; January 1997)(Continuation line clarifications: April 1997)(GLONASS Extensions: April 1997)(Met sensor description and position records: April 1997)(Wavelength factor clarifications: April 1997)Werner GurtnerAstronomical InstituteUniversity of Berne0. INTRODUCTION0.1 First RevisionThis paper is a revised version of the one published by W. Gurtner and G.Mader in the CSTG GPS Bulletin of September/October 1990. The main reasonfor a revision is the new treatment of antispoofing data by the RINEXformat (see chapter 7). Chapter 4 gives a recommendation for data compression procedures, especially useful when large amounts of data are exchanged through computer networks. In Table A3 in the original paper the definiton of the "PGM / RUN BY / DATE" navigation header record was missing, although the example showed it. The redefinition of AODE/AODC to IODE/IODC also asks for an update of the format description. For consistency reasons we also defined a Version 2 format for the Meteorological Data files(inclusion of a END OF HEADER record and an optional MARKER NUMBER record).* The slight modification (or rather the definition of a bit in the Loss ** of Lock Indicator unused so far) to flag AS data is so small a change ** that we decided to NOT increase the version number! *0.2 Later Revisions:* URA Clarification (10-Dec-93):The user range accuracy in the Navigation Message File did not contain a definition of the units: There existed two ways of interpretation:Either the 4 bit value from the original message or the converted value in meters according to GPS ICD-200. In order to simplify the interpretation for the user of the RINEX files I propose the bits to be converted into meters prior to RINEX file creation.* GLONASS Extensions:In March 1997 a proposal for extensions to the current RINEX definitions based on experiences collected with GLONASS only and mixed GPS/GLONASS data files was circulated among several instrument manufacturers and software developers.The results of the call for comments have been worked into this document.A separate document (glonass.txt) summarizes just the necessary extensions.* A blank satellite identifier is allowed in pure GPS files only* Met sensor description and position records were added to facilitate the precise use of met values.* Description and examples for wavelength factors and their temporary changes(bit 1 of LLI) clarified.In order to have all the available information about RINEX in one place we also included parts of earlier papers and a complete set of format definiton tables and examples.1. THE PHILOSOPHY OF RINEXThe first proposal for the "Receiver Independent Exchange Format" RINEX has been developed by the Astronomical Institute of the University of Berne for the easy exchange of the GPS data to be collected during the large European GPS campaign EUREF 89, which involved more than 60 GPS receivers of 4 different manufacturers. The governing aspect during the development was the following fact:Most geodetic processing software for GPS data use a well-defined set of observables:- the carrier-phase measurement at one or both carriers (actually being a measurement on the beat frequency between the received carrier of the satellite signal and a receiver-generated reference frequency).- the pseudorange (code) measurement, 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.- the observation time being the reading of the receiver clock at the instant of validity of the carrier-phase and/or the code measurements.Usually the software assumes that the observation time is valid for both the phase AND the code measurements, AND for all satellites observed.Consequently all these programs do not need most of the information that is usually stored by the receivers: They need phase, code, and time in the above mentioned definitions, and some station-related information like station name, antenna height, etc.2. GENERAL FORMAT DESCRIPTIONCurrently the format consists of four ASCII file types:1. Observation Data File2. Navigation Message File3. Meteorological Data File4. GLONASS Navigation Message FileEach file type consists of a header section and a data section. The header section contains global information for the entire file and is placed at the beginning of the file. The header section contains header labels in columns 61-80 for each line contained in the header section. These labels are mandatory and must appear exactly as given in these descriptions and examples.The format has been optimized for mimimum space requirements independent from the number of different observation types of a specific receiver by indicating in the header the types of observations to be stored. In computer systems allowing variable record lengths the observation records may then be kept as short as possible. The maximum record length is 80 bytes per record.Each Observation file and each Meteorological Data file basically contain the data from one site and one session. RINEX Version 2 also allows to include observation data from more than one site subsequently occupied by a roving receiver in rapid static or kinematic applications.If data from more than one receiver has to be exchanged it would not be economical to include the identical satellite messages collected by the different receivers several times. Therefore the Navigation Message File from one receiver may be exchanged or a composite Navigation MessageFile created containing non-redundant information from several receivers in order to make the most complete file.The format of the data records of the RINEX Version 1 Navigation Message file is identical to the former NGS exchange format.The actual format descriptions as well as examples are given in the Tables at the end of the paper.3. DEFINITION OF THE OBSERVABLESGPS observables include three fundamental quantities that need to be defined: Time, Phase, and Range.TIME:The time of the measurement is the receiver time of the received signals. It is identical for the phase and range measurements and is identical for all satellites observed at that epoch. It is expressed in GPS time (not Universal Time).PSEUDO-RANGE:The pseudo-range (PR) is the distance from the receiver antenna to the satellite antenna including receiver and satellite clock offsets (and other biases, such as atmospheric delays):PR = distance + c * (receiver clock offset - satellite clock offset + other biases)so that the pseudo-range reflects the actual behavior of the receiver and satellite clocks. The pseudo-range is stored in units of meters.See also clarifications for pseudoranges in mixed GPS/GLONASS files in chapter 8.1.PHASE:The phase is the carrier-phase measured in whole cycles at both L1 and L2. The half-cycles measured by sqaring-type receivers must be converted to whole cycles and flagged by the wavelength factor in the header section.The phase changes in the same sense as the range (negative doppler). The phase observations between epochs must be connected by including the integer number of cycles. The phase observations will not contain any systematic drifts from intentional offsets of the reference oscillators.The observables are not corrected for external effects like atmospheric refraction, satellite clock offsets, etc.If the receiver or the converter software adjusts the 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:Time(corr) = Time(r) - dT(r)PR(corr) = PR(r) - dT(r)*cphase(corr) = phase(r) - dT(r)*freqDOPPLER:The sign of the doppler shift as additional observable is defined as usual:Positive for approaching satellites.4. THE EXCHANGE OF RINEX FILES:We recommend using the following naming convention for RINEX files:ssssdddf.yyt ssss: 4-character station name designatorddd: day of the year of first recordf: file sequence number within day0: file contains all the existingdata of the current dayyy: yeart: file type:O: Observation fileN: Navigation fileM: Meteorological data fileG: GLONASS Navigation fileTo exchange RINEX files on magnetic tapes we recommend using the following tape format:- Non-label; ASCII; fixed record length: 80 characters;block size: 8000- First file on tape contains list of files using above-mentioned naming conventionsWhen 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.Proposed naming conventions for the compressed files:System Obs files GPS Nav Files GLONASS Nav Files Met FilesUNIX ssssdddf.yyO.Z ssssdddf.yyN.Z ssssdddf.yyG.Z ssssdddf.yyM.ZVMS ssssdddf.yyO_Z ssssdddf.yyN_Z ssssdddf.yyG_Z ssssdddf.yyN_ZDOS ssssdddf.yyY ssssdddf.yyX ssssdddf.yyV ssssdddf.yyW5. RINEX VERSION 2 FEATURESThe following section contains features that have been introduced for RINEX Version 2.5.1 Satellite Numbers: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.snn s: satellite system identifierG or blank : GPSR : GLONASST : Transitnn :PRN (GPS), almanac number (GLONASS) or two-digit Transit satellite numberNote: G is mandatory in mixed GPS/GLONASS files(blank default modified in April 1997)5.2 Order of the Header Records: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.We therefore propose to allow free ordering of the header records, with the following exceptions:- The "RINEX VERSION / TYPE" record must be the first record in a file- The default "WAVELENGTH FACT L1/2" record (if present) should precede all records defining wavelength factors for individual satellites- 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.5.3 Missing Items, Duration of the Validity of ValuesItems that are not known at the file creation time can be set to zero or blank or the respectiverecord 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.5.4. Event Flag RecordsThe "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.5.5 Receiver Clock OffsetA 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.6. ADDITIONAL HINTS AND TIPSPrograms 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 featuresWe 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.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.7. RINEX UNDER ANTISPOOFING (AS)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.Other receivers recover P code observations by breaking down the Y code into P and W code.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).8. GLONASS Extensions8.1 RINEX Observation file8.1.1 Time System IdentifierRINEX Version 2 needs one major supplement, the explicit definition of the time system: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.Format definitions see Table A1.Hence, the two possible time tags differ by the current number of leap seconds.In order to have the current number of leap seconds available we recommend to include a LEAP SECOND line into the RINEX header.If there are known non-integer biases between the "GPS receiver clock" and "GLONASS receiver clock" in the same receiver, they should be applied.In this case the respective code and phase observations have to be corrected,too (c * bias if expressed in meters).Unknown such biases will have to be solved for during the post processingThe 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.8.1.2 Pseudorange DefinitionThe 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.If a mixed-mode GPS/GLONASS receiver refers all pseudorange observations to one receiver clock only,- 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- 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 frameIn order to avoid misunderstandings and to keep the code observations within the format fields, the pseudoranges must be corrected in this case as follows:PR(GPS) := PR(GPS) + c * leap_seconds if generated with a receiver clock running in the GLONASS time framePR(GLO) := PR(GLO) - c * leap_seconds if generated with a receiver clock running in the GPS time frameto remove the contributions of the leap seconds from the pseudoranges."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.8.1.3 More than 12 satellites per epochThe format of the epoch / satellite line in the observation record part of the RINEX Observation files has only been defined for up to 12 satellites per epoch. We explicitly define now the format of the continuation lines, see table A2.8.2 RINEX Navigation Files for GLONASSAs the GLONASS navigation message differs in contents from the GPS message too much, a special GLONASS navigation message file format has been defined.The header section and the first data record (epoch, satellite clock information) is similar to the GPS navigation file. The following records contain the satellite position, velocity and acceleration, the clock and frequency biases as well as auxiliary information as health, satellite frequency (channel), age of the information.*** In order to use the same sign conventions for the time and frequency bias as in the GPS navigation files, the broadcast GLONASS values are multiplied by -1.The time tags in the GLONASS navigation files are given in UTC (i.e. _not_Moscow time or GPS time).Filenaming convention: See above.9. REFERENCESEvans, A. (1989): "Summary of the Workshop on GPS Exchange Formats." Proceedings of the Fifth International Geodetic Symposium on Satellite Systems, pp. 917ff, Las Cruces.Gurtner, W., G. Mader, D. Arthur (1989): "A Common Exchange Format for GPS Data." CSTG GPS Bulletin Vol.2 No.3, May/June 1989, National Geodetic Survey, Rockville.Gurtner, W., G. Mader (1990): "The RINEX Format: Current Status, Future Developments." Proceedings of the Second International Symposium of Precise Positioning with the Global Positioning system, pp. 977ff, Ottawa.Gurtner, W., G. Mader (1990): "Receiver Independent Exchange Format Version 2." CSTG GPS Bulletin Vol.3 No.3, Sept/Oct 1990, National Geodetic Survey, Rockville.10. RINEX VERSION 2 FORMAT DEFINITIONS AND EXAMPLES+----------------------------------------------------------------------------+| TABLE A1 || OBSERVATION DATA FILE - HEADER SECTION DESCRIPTION |+--------------------+------------------------------------------+------------+| HEADER LABEL | DESCRIPTION | FORMAT || (Columns 61-80) | | |+--------------------+------------------------------------------+------------+|RINEX VERSION / TYPE| - Format version (2) | I6,14X, || | - File type ('O' for Observation Data) | A1,19X, || | - Satellite System: blank or 'G': GPS | A1,19X || | 'R': GLONASS | || | 'T': NNSS Transit | || | 'M': Mixed | |+--------------------+------------------------------------------+------------+|PGM / RUN BY / DATE | - Name of program creating current file | A20, || | - Name of agency creating current file | A20, || | - Date of file creation | A20 |+--------------------+------------------------------------------+------------+*|COMMENT | Comment line(s) | A60 |*+--------------------+------------------------------------------+------------+|MARKER NAME | Name of antenna marker | A60 |+--------------------+------------------------------------------+------------+*|MARKER NUMBER | Number of antenna marker | A20 |*+--------------------+------------------------------------------+------------+|OBSERVER / AGENCY | Name of observer / agency | A20,A40 | +--------------------+------------------------------------------+------------+ |REC # / TYPE / VERS | Receiver number, type, and version | 3A20 | | | (Version: e.g. Internal Software Version)| | +--------------------+------------------------------------------+------------+ |ANT # / TYPE | Antenna number and type | 2A20 | +--------------------+------------------------------------------+------------+ |APPROX POSITION XYZ | Approximate marker position (WGS84) | 3F14.4 | +--------------------+------------------------------------------+------------+ |ANTENNA: DELTA H/E/N| - Antenna height: Height of bottom | 3F14.4 | | | surface of antenna above marker | | | | - Eccentricities of antenna center | | | | relative to marker to the east | | | | and north (all units in meters) | | +--------------------+------------------------------------------+------------+ |WAVELENGTH FACT L1/2| - Wavelength factors for L1 and L2 | 2I6, | | | 1: Full cycle ambiguities | | | | 2: Half cycle ambiguities (squaring) | | | | 0 (in L2): Single frequency instrument | | | | - Number of satellites to follow in list | I6, | | | for which these factors are valid. | | | | 0 or blank: Default wavelength factors | | | | for all satellites not contained in | | | | such a list. | | | | - List of PRNs (satellite numbers) | 7(3X,A1,I2)| | | | | | | Repeat record if necessary | | +--------------------+------------------------------------------+------------+ |# / TYPES OF OBSERV | - Number of different observation types | I6, | | | stored in the file | | | | - Observation types | 9(4X,A2) | | | | | | | If more than 9 observation types: | | | | Use continuation line(s) |6X,9(4X,A2) | | | | | | | The following observation types are | | | | defined in RINEX Version 2: | | | | | | | | L1, L2: Phase measurements on L1 and L2 | | | | C1 : Pseudorange using C/A-Code on L1 | | | | P1, P2: Pseudorange using P-Code on L1,L2| | | | D1, D2: Doppler frequency on L1 and L2 | | | | T1, T2: Transit Integrated Doppler on | | | | 150 (T1) and 400 MHz (T2) | || | | | | | Observations collected under Antispoofing| | | | are converted to "L2" or "P2" and flagged| | | | with bit 2 of loss of lock indicator | | | | (see Table A2). | | | | | | | | Units : Phase : full cycles | | | | Pseudorange : meters | | | | Doppler : Hz | | | | Transit : cycles | | | | | | | | The sequence of the types in this record | | | | has to correspond to the sequence of the | | | | observations in the observation records | | +--------------------+------------------------------------------+------------+ *|INTERVAL | Observation interval in seconds | I6 |* +--------------------+------------------------------------------+------------+ |TIME OF FIRST OBS | - Time of first observation record | 5I6,F12.6, | | | (4-digit-year, month,day,hour,min,sec) | | | | - Time system: GPS (=GPS time system) | 6X,A3 | | | GLO (=UTC time system) | | | | Compulsory in mixed GPS/GLONASS files | | | | Defaults: GPS for pure GPS files | | | | GLO for pure GLONASS files | | +--------------------+------------------------------------------+------------+ *|TIME OF LAST OBS | - Time of last observation record | 5I6,F12.6, |* | | (4-digit-year, month,day,hour,min,sec) | | | | - Time system: GPS (=GPS time system) | 6X,A3 | | | GLO (=UTC time system) | | | | Compulsory in mixed GPS/GLONASS files | | | | Defaults: GPS for pure GPS files | | | | GLO for pure GLONASS files | | +--------------------+------------------------------------------+------------+ *|LEAP SECONDS | Number of leap seconds since 6-Jan-1980 | I6 |* | | Recommended for mixed GPS/GLONASS files | | +--------------------+------------------------------------------+------------+ *|# OF SATELLITES | Number of satellites, for which | I6 |* | | observations are stored in the file | | +--------------------+------------------------------------------+------------+ *|PRN / # OF OBS | PRN (sat.number), number of observations |3X,A1,I2,9I6|* | | for each observation type indicated | | | | in the "# / TYPES OF OBSERV" - record. | | | | | | | | If more than 9 observation types: | || | Use continuation line(s) | 6X,9I6 | | | | | | | This record is (these records are) | | | | repeated for each satellite present in | | | | the data file | | +--------------------+------------------------------------------+------------+ |END OF HEADER | Last record in the header section. | 60X | +--------------------+------------------------------------------+------------+Records marked with * are optional+----------------------------------------------------------------------------+ | TABLE A2 | | OBSERVATION DATA FILE - DATA RECORD DESCRIPTION | +-------------+-------------------------------------------------+------------+ | OBS. RECORD | DESCRIPTION | FORMAT | +-------------+-------------------------------------------------+------------+ | EPOCH/SAT | - Epoch : | 5I3,F11.7, | | or | year (2 digits), month,day,hour,min,sec | | | EVENT FLAG | - Epoch flag 0: OK | I3, | | | 1: power failure between | | | | previous and current epoch | | | | 1: Event flag | | | | - Number of satellites in current epoch | I3, | | | - List of PRNs (sat.numbers) in current epoch | 12(A1,I2), | | | - receiver clock offset (seconds, optional) | F12.9 | | | | | | | If more than 12 satellites: Use continuation | 32X, | | | line(s) | 12(A1,I2) | | | | | | | If EVENT FLAG record (epoch flag 1): | | | | - Event flag: | | | | 2: start moving antenna | | | | 3: new site occupation (end of kinem. data) | | | | (at least MARKER NAME record follows) | | | | 4: header information follows | | | | 5: external event (epoch is significant, | | | | same time frame as observation time tags)| | | | 6: cycle slip records follow to optionally | | | | report detected and repaired cycle slips | | | | (same format as OBSERVATIONS records; | | | | slip instead of observation; LLI and | | | | signal strength blank) | || | - "Number of satellites" contains number of | | | | records to follow (0 for event flags 2,5) | | +-------------+-------------------------------------------------+------------+ |OBSERVATIONS | - Observation | rep. within record for | m(F14.3, | | | - LLI | each obs.type (same seq | I1, | | | - Signal strength | as given in header) | I1) | | | | | | | If more than 5 observation types (=80 char): | | | | continue observations in next record. | | | | | | | | This record is (these records are) repeated for | | | | each satellite given in EPOCH/SAT - record. | | | | | | | | Observations: | | | | Phase : Units in whole cycles of carrier | | | | Code : Units in meters | | | | Missing observations are written as 0.0 | | | | or blanks. | | | | Loss of lock indicator (LLI). Range: 0-7 | | | | 0 or blank: OK or not known | | | | Bit 0 set : Lost lock between previous and | | | | current observation: cycle slip | | | | possible | | | | Bit 1 set : Opposite wavelength factor to the | | | | one defined for the satellite by a | | | | previous WAVELENGTH FACT L1/2 line.| | | | Valid for the current epoch only. | | | | Bit 2 set : Observation under Antispoofing | | | | (may suffer from increased noise) | | | | | | | | Bits 0 and 1 for phase only. | | | | | | | | Signal strength projected into interval 1-9: | | | | 1: minimum possible signal strength | | | | 5: threshold for good S/N ratio | | | | 9: maximum possible signal strength | | | | 0 or blank: not known, don't care | | +-------------+-------------------------------------------------+------------++----------------------------------------------------------------------------+ | TABLE A3 | | NAVIGATION MESSAGE FILE - HEADER SECTION DESCRIPTION | +--------------------+------------------------------------------+------------+。
rinex文件压缩原理
rinex文件压缩原理RINEX文件是一种用于存储全球定位系统（GPS）和全球卫星导航系统（GNSS）数据的格式。
对于GNSS数据处理和分析，RINEX文件是必不可少的。
由于RINEX文件大小通常很大，因此需要进行压缩以减小文件大小并提高数据传输速率。
这篇文章将介绍RINEX文件压缩的原理。
RINEX文件压缩的目的是通过消除文件中的冗余信息来减小文件的大小。
在RINEX文件中，时间标签和卫星信号标签被重复使用。
例如，在不同的卫星信号记录中，时间标签和卫星信号标签是相同的。
因此，这些信息可以被压缩并存储在文件头中。
RINEX文件的压缩可以分为两个步骤：头部压缩和数据压缩。
头部压缩首先将RINEX文件头部分解析成一个结构体，然后压缩头部结构体。
通过下面的步骤可以达到压缩头部的目的：1、记录RINEX文件格式版本号；2、记录观测站信息、类型以及位置信息；3、记录卫星系统发射时间（GPS、GLONASS等）；4、记录流媒体协议的版本号以及具体参数；5、记录观测站周转角以及天线的参考位置；6、记录无电离层组合参数；数据压缩RINEX文件数据部分的压缩需要考虑到时间标签和卫星信号标签的重复使用，同时还要注意数据格式的保持。
在文本文件中，通常使用空格或制表符作为数据的分隔符。
这些不可见的字符也需要考虑到。
1、按时间标签分割数据，每个时间点上的数据都是相同的；2、在每个时间点上，按照卫星信号标签分割数据，每个标签对应一组数据；3、对于每组数据，在第一个数据前添加卫星信号标签以及其它必要的信息；4、使用无符号整数压缩存储时间间隔信息；5、压缩数据，采用位压缩算法，把每个数据中的空格转换成一个位。
总的来说，RINEX文件压缩可以显著减小文件大小，并且可以加快数据传输速度。
压缩需要用到一些算法，需要注意数据格式的保持。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第61-80列，从零开始计数
描述
格式
RINEX VERSION / TYPE
-版本(2.10)
-文件类型('N'表示导航文件)
F9.2,11X,
A1,19X
PGM / RUN BY / DATE
-创建当前文件的程序名称
-创建当前文件的机构名称
-创建文件的时间
A20,
A20,
A20
*COMMENT
不同的观测类型中，观测到的卫星数量
如果超过9种类型下行继续
3X,A1,I2,9I6
6X,9I6
END OF HEADER
文件头部分的最后一行
60X
2)观测文件数据记录
观测记录
描述
格式
EPOCH/SAT
or
EVENT FLAG
-星历:
-年(2字节需要时补0)
-月,日,时,分,
-秒
-星历标志0: OK
1:从前一历元到当前历元观测失败
-时间系统：GPS（GPS时间系统）
GLO（UTC时间系统）
5I6,F13.7,
5X,A3
*RCV CLOCK OFFS APPL
是否用实时接收机时钟补偿来修正星历、码和相位，1=yes, 0=no
I6
*LEAP SECONDS
跳秒
I6
*# OF SATELLITES
观测到的卫星数量
I6
*PRN / # OF OBS
RINEX(Receiver Independent Exchange)，共有三种格式观测文件、导航文件和气象文件（meteorological）。
1.1.1.1
1.观测文件
1)观测文件的文件头
带*的内容为可选内容，在格式中，以类型开头，紧跟所占字节数。
F（float）表示浮点数，如F9.2理解为9位（含小数点）浮点数，保留到小数点后两位；
2X,I1,
I3,
12(A1,I2),
F12.9
32X,
12(A1,I2)
[2X,I1,]
[I3]
OBSERVATIONS
-观测值
- LLI
-信号强度
如果超过5种观测类型（80字节）：下行继续
同一历元中的所有卫星，对应一条记录
观测值:
相位:单位周
相位:单位米
如果没有观测则记录0或记录为空
相位观测值溢出F14.3，必须进行截断,用LLI表明.
L1, L2: L1、L2载波相位测量
C1: L1载波C/A码伪距测量
P1, P2: L1,L2载波P码伪距测量
D1, D2: L1、L2载波多普勒频率测量
T1, T2:
S1, S2:
单位：
Phase:周
Pseudorange :米
Doppler:赫兹
Transit:周
SNR etc:
I6,
9(4X,A2)
6X,9(4X,A2)
*INTERVAL
以秒为单位的观测间隔
F10.3
TIME OF FIRST OBS
-初次观测时间
（四字节年，月、日、时、分、秒）
-时间系统：GPS（GPS时间系统）
GLO（UTC时间系统）
5I6,F13.7,
5X,A3
*TIME OF LAST OBS
-最后观测时间
（四字节年，月、日、时、分、秒）
标记点概略位置（WGS84）
3F14.4
ANTENNA: DELTA H/E/N
-天线高度：天线底部相交于标记点的高度
-天线中心相对标记点东向和北向距离（单位米）
3F14.4
WAVELENGTH FACT L1/2
- L1和L2载波的缺省系数
1:整周
2:半周
0 (L2载波):单频接收机
- 0或空格
2I6,
>1:事件标志
-当前历元的卫星数量
-当前观测到的卫星列表
-接收机钟差（秒，可选）
如果超过12颗卫星，下行继续
-事件标志:
2:开始移动天线
3:新地点
4:接下来是头信息
5:其它事件
6:
-卫星数量包含记下来的记录集的数量，最多999
-没有有意义的星历，星历记录可为空
A1,19X,
4(1X,I2),
F11.7,
跳秒
I6
END OF HEADER
文件头部分的最后一行
60X
2)导航文件数据记录
观测记录
描述
格式
PRN / EPOCH / SV CLK
-卫星编号
-星历: Toc –时钟时间
年(2字节，根据需要可补零)
月
日
时
分
秒
- SV钟偏(seconds)
- SV钟漂(sec/sec)
注释语句
A60
*ION ALPHA
历元的电离层参数A0-A3
2X,4D12.4
*ION BETA
历元的电离层参数B0-B3
2X,4D12.4
*DELTA-UTC: A0,A1,T,W
用于计算UTC的参数
A0,A1:多项式系数
T :UTC参考时间
W : UTC参考周
3X,2D19.12, 2I9
*LEAP SECONDS
LLI范围: 0-7
0或空格:正常或不确定
字节0置为:前一观测和当前观测之间可能失锁
字节1置位:
字节2置位:
字节0和字节1只适用于相位.
信号强度设为1-9级:
1:最小信号强度
5:好信噪比S/N门限
9:最大信号强度
0或空:不确定
m(F14.3,
I1,
I1)
1.1.1.2
1.导航文件
1)导航文件的文件头
A60
MARKER NAME
标记点名称
A60
*MARKER NUMBER
标记点数量
A60
OBSERVER / AGENCY
观测者的名称和所在机构
A20,A40
REC # / TYPE / VERS
接收机数量、型号和版本
3A20
ANT # / TYPE
天线数量、型号
2A20
APPROX POSITION XYZ
版本格式（2.10）
文件类型
导航系统：空格或’G’：GPS
‘R’：GLONASS
‘S’：
‘T’：
‘M’：混合
F9.2,11X,
A1,19X,
A1,19X
PGM / RUN BY / DATE
-创建当前文件的程序名称
-创建当前文件的机构名称
-创建文件的*COMMENT
注释语句（可多行）
I6
*WAVELENGTH FACT L1/2
- L1和L2载波的缺省系数
1:整周
2:半周
0 (L2载波):单频接收机
-系数适用的卫星数据
-系数适用的卫星列表
2I6,
I6,
7(3X,A1,I2)
# / TYPES OF OBSERV
-文件中观测类型数量
-观测类型
如果超过9种观测类型，下行继续
观测类型：
X表示空格，如11X表示11位空位；
A（ASCII）表示ASCII字码，如A1表示1位ASCII字码；
I（integer）表示整数，如I6表示，6位整数；
数据和数据之间以“，”隔开；
连续多个相同类型则在类型前面加上总个数，如2I6表示两组6位整数。
标签
第61-80列，从零开始计数
描述
格式
RINEX VERSION / TYPE