Skip to content

RINEX-2 BDS, QZSS, IRNSS support

As an extension to the RINEX-2.11 standard, the BEIDOU-, QZSS-, IRNSS- satellite systems are formally supported.

In the RINEX-2 standard, there are no extension letters defined for single system BEIDOU-, QZSS-, IRNSS- single system navigation files. The following characters are used by gfzrnx:

System Letter Example
BDS c pots0750.17c
QZSS j pots0750.17j
IRNSS i pots0750.17i

RINEX-2 to RINEX-3 or 4 conversion

The RINEX-3.03 standard (and higher) does not allow an empty attribute identifier (tracking mode or channel) in observation type naming (tna - observation type|band/frequency|attribute). Converting files from RINEX-2 to RINEX-3 shows the problem of safely map 2-characters to 3-characters observation type names (e.g. L2 to L2?). As it is not foreseen to have an "unknown" or "converted" attribute identifier, the output version used is 3.01 to stay format conform.

Handling of unsupported observation types

gfzrnx s driven by hard-coded observation types, and the mapping table is compliant with RINEX standards. Running the program for unsupported or non-standard observation types results in the omitting of these data. To avoid this behavior, one has to extend the standard. This can be done with the following procedure:

  • Extract the hardcoded table from the gfzrnx executable.
gfzrnx -out_obs_map
gfzrnx -out_obs_map -fout obs_types_map.txt
  • Add new observation types records to the map. The information in the columns 2,3 and 4 is treated as a comment only and is not used.
  • Run any gfzrnx command call with the modified table.
gfzrnx -use_obs_map obs_types_map.txt -finp ...

Please use this feature with special caution

Be aware that this undermines the given RINEX standard and can be an error source if not used properly. The generated files are for internal use only!