-Observations will be converted to RINEX if they come in either RTCM Version 2 or RTCM Version 3 format. Depending on the RINEX version and incoming RTCM message types, the files generated by BNC may contain data from GPS, GLONASS, Galileo, SBAS, QZSS and COMPASS. In case an observation type is listed in the RINEX header but the corresponding observation is unavailable, its value is set to zero '0.000'. Note that the 'RINEX TYPE' field in the RINEX Version 3 Observation file header is always set to 'M(MIXED)' or 'Mixed' even if the file only contains data from one system. -
+Observations will be converted to RINEX if they come in either RTCM Version 2 or RTCM Version 3 format. Depending on the RINEX version and incoming RTCM message types, files generated by BNC may contain data from GPS, GLONASS, Galileo, SBAS, QZSS and COMPASS. In case an observation type is listed in the RINEX header but the corresponding observation is unavailable, its value is set to zero '0.000'. Note that the 'RINEX TYPE' field in the RINEX Version 3 Observation file header is always set to 'M(MIXED)' or 'Mixed' even if the file only contains data from one system. + ++It is important to understand that converting RTCM streams to RINEX files requires a-priori information on observation types for specifying a complete RINEX header. Regarding the RINEX Version 2 file header BNC simply introduces all observation types defined in the Version 2 standard and later reports "0.000" for all observations which are not received. However, following this approach is not possible for RINEX Version 3 files from RTCM Version 3 MSM streams because of the huge number of observation types which might in principle show up. The solution implemented in BNC is to start with RINEX Version 3 observation type records from skeleton files (see section 'Skeleton Extension') and switch to a default selection of observation types when such skeleton file is not available. +
@@ -439,7 +442,4 @@
Figure 6: BNC translating incoming streams to 15 min RINEX Version 3 files.
--Converting RTCM streams to RINEX files requires a-priori information on observation types for specifying a complete RINEX header. Regarding the RINEX Version 2 file header BNC simply introduces all observation types defined in the Version 2 standard and later reports "0" for all observations which are not received. However, following this approach is not possible for RINEX Version 3 files from RTCM Version 3 MSM streams because of the huge number of observation types which might in principle show up. The intended solution for BNC is to start with RINEX Version 3 observation type records read from skeleton files (see section 'Skeleton Extension') and switch to a default selection of observation types when such skeleton file is not available. -
@@ -491,8 +491,8 @@3.4.5 Skeleton Extension - optional
-Whenever BNC starts generating RINEX Observation files (and then once every day at midnight), it first tries to retrieve information needed for RINEX headers from so-called public RINEX header skeleton files which are derived from sitelogs. A HTTP link to a directory containing these skeleton files may be available through data field number 7 of the affected NET record in the source-table. See http://www.epncb.oma.be:80/stations/log/skl/brus.skl for an example of a public RINEX Version 2 header skeleton file for the Brussels EPN station. -
--However, sometimes public RINEX header skeleton files are not available, thair contents is not up to date, or you need to put additional/optional records in the RINEX header. For that BNC allows using personal skeleton files that contain the header records you would like to include. You can derive a personal RINEX header skeleton file from the information given in an up to date sitelog. A file in the RINEX Observations 'Directory' with a 'Skeleton extension' suffix is interpreted by BNC as a personal RINEX header skeleton file for the corresponding stream. +Whenever BNC starts generating RINEX Observation files (and then once every day at midnight), it first tries to retrieve information needed for RINEX headers from so-called public RINEX header skeleton files which are derived from sitelogs. A HTTP link to a directory containing these skeleton files may be available through data field number 7 of the affected NET record in the source-table. See http://www.epncb.oma.be:80/stations/log/skl/brus.skl for an example of a public RINEX header skeleton file for the Brussels EPN station. +
++However, sometimes public RINEX header skeleton files are not available, their contents is not up to date, or you need to put additional/optional records in the RINEX header. For that BNC allows using personal skeleton files that contain the header records you would like to include. You can derive a personal RINEX header skeleton file from the information given in an up to date sitelog. A file in the RINEX Observations 'Directory' with a 'Skeleton extension' suffix is interpreted by BNC as a personal RINEX header skeleton file for the corresponding stream.
@@ -512,6 +512,5 @@
-The following is a skeleton example for a RINEX Version 2 file: +The following is a skeleton example for a RINEX file:
- OBSERVATION DATA G (GPS) RINEX VERSION / TYPE
+ OBSERVATION DATA M (Mixed) RINEX VERSION / TYPE
DUND MARKER NAME
50212M003 MARKER NUMBER
-4635120796 TRIMBLE NETRS 1.15 REC # / TYPE / VERS
+4635120796 TRIMBLE NETR9 1.15 REC # / TYPE / VERS
12626150 TRM41249.00 NONE ANT # / TYPE
-4388121.1700 726671.0500 -4556535.6300 APPROX POSITION XYZ
0.0020 0.0000 0.0000 ANTENNA: DELTA H/E/N
GeoNet Reception GNS OBSERVER / AGENCY
+G 28 21C L1C D1C S1C C1W L1W D1W S1W C5X L5X D5X S5X C2W SYS / # / OBS TYPES
+ L2W D2W S2W C2X L2X D2X S2X SYS / # / OBS TYPES
+R 16 C1C L1C D1C S1C C1P L1P D1P S1P C2P L2P D2P S2P C2C SYS / # / OBS TYPES
+ L2C D2C S2C SYS / # / OBS TYPES
+S 12 C1C L1C D1C S1C C1W L1W D1W S1W C5I L5I D5I S5I SYS / # / OBS TYPES
+E 8 C1 L1 D1 S1 C5 L5 D5 S5 SYS / # / OBS TYPES
+C 4 C2I L2I D2I S2I SYS / # / OBS TYPES
+J 12 C1C L1C D1C S1C C2 L2 D2 S2 C5 L5 D5 S5 SYS / # / OBS TYPES
PORTIONS OF THIS HEADER GENERATED BY BKG FROM COMMENT
SITELOG dund_20070806.log COMMENT
@@ -2555,5 +2562,5 @@
Aug 2012 Version 2.7
-[Bug] Bug in L5 decoding fixed
[Bug] Bug in on-the-fly configuration fixed
[Add] Clock RINEX file header extended
[Add] Decoding/converting COMPASS and QZSS added
[Add] Work on RINEX v2 and v3 quality check started
[Mod] Source code completely re-arranged
[Add] QWT and QWTPOLAR graphics libraries added
[Add] RINEX v2 and v3 quality check through multipath analysis and sky plot
[Bug] Short periodic outages in PPP time series when operated when 'Sync Corr' set to zero
[Add] Version 2.7 published
+[Bug] Bug in L5 decoding fixed
[Bug] Bug in on-the-fly configuration fixed
[Add] Clock RINEX file header extended
[Add] Decoding/converting COMPASS and QZSS added
[Add] Work on RINEX v2 and v3 quality check started
[Mod] Source code completely re-arranged
[Add] QWT and QWTPOLAR graphics libraries added
[Add] RINEX v2 and v3 quality check through multipath analysis and sky plot
[Bug] Short periodic outages in PPP time series when operated when 'Sync Corr' set to zero
[Add] Reading RINEX v3 Observation Type header records from RINEX skeleton files
[Add] Save PNG plot files on disk
[Add] Version 2.7 published
@@ -2693,4 +2700,11 @@
+The following is proposed Galileo Navigation Message under discussion for standardization:
+
The following are so-called 'State Space Representation' (SSR) messages:
The following are proposed 'Multiple Signal Messages' (MSM) under discussion for standardization: