-BNC is written under GNU General Public License (GPL). Binaries for BNC are available for Windows, Linux, and Solaris systems. It is likely that BNC can be compiled on other systems where a GNU compiler and Qt Version 4 are available. +BNC is written under GNU General Public License (GPL). Binaries for BNC are available for Windows, Linux, and Solaris systems. It is likely that BNC can be compiled on other systems where a GNU compiler and Qt Version 4.0.1 are available.
-BNC decodes and converts GNSS data streams carrying phase data coming in -
--You may like to run BNC in a Local Area Network (LAN). LAN's are often protected by a proxy server. Enter your proxy server IP and port number in case one is operated in front of BNC. If you don't know the IP and port of your proxy server, check out the proxy server settings of your Windows browser or ask your network administrator.
+You may like to run BNC in a Local Area Network (LAN). LAN's are often protected by a proxy server. Enter your proxy server IP and port number in case one is operated in front of BNC. If you don't know the IP and port of your proxy server, check out the proxy server settings of your Internet browser or ask your network administrator.
Note that IP streaming may be generally denied in a LAN. In such a case you need to request an appropriate modification of the security policy from your network administrator or ask for the installation of a TCP relay to involved NTRIP broadcasters. If that doesn't work out, run BNC on a host that is connected to the Internet through an Internet Service Provider (ISP).
@@ -118,6 +118,6 @@
B - 4. Synchronized Output
-BNC lets you output synchronized observations epoch by epoch. This output is made available in ASCII format and in a binary format. The output comprises the following observations if available:
-StatID, SVPRN, GPSWeek, GPSWeeks, sec, C1 or P1, P2, L1, L2, SNR1, SNR2, pCodeIndicator, cumuLossOfCont. +BNC lets you output synchronized observations epoch by epoch. This output is made available in a plain ASCII format and in a binary format. The output comprises the following observations if available: +StatID, SVPRN, GPSWeek, GPSWeeks, sec, C1, P1, P2, L1, L2, SNR1, SNR2, pCodeIndicator, cumuLossOfCont. @@ -140,5 +140,5 @@-BNC makes synchronized observations available in a binary format on your local host IP 127.0.0.1 through an IP port. Enter an IP port number to activate this function. Default is an empty option field, meaning that no binary output is generated.
+BNC makes synchronized observations available in a binary format on your local host (IP 127.0.0.1) through an IP port. Enter an IP port number to activate this function. Default is an empty option field, meaning that no binary output is generated.The binary output is provided as a continuous stream in the order
@@ -184,5 +184,5 @@-Note that RINEX file names for all intervals less than 1 hour are created following the file name convention for 15 minute RINEX files. +Note that RINEX file names for all intervals less than 1 hour follow the file name convention for 15 minutes RINEX files.
@@ -196,5 +196,5 @@B - 5.2 RINEX Script - optional
-Whenever a RINEX file is generated, you may like to compress, copy, or upload it immediately via FTP. For that you enter the full path of a script or batch file carrying out these operations. The RINEX file path will be passed to the script as a command line parameter (%1 on Windows systems, $1 on Unix/Linux systems). +Whenever a RINEX file is saved, you may like to compress, copy, or upload it immediately via FTP. For that you enter the full path of a script or batch file carrying out these operations. The RINEX file path will be passed to the script as a command line parameter (%1 on Windows systems, $1 on Unix/Linux systems).
@@ -217,5 +217,5 @@-Example: Mountpoint FRAN0 leads to the generation of RINEX file FRAN*.*. The header part of this file would be overwritten by the content of an existing skeleton file named FRAN.skl if 'RINEX skeleton extension' is set to 'skl' . +Example: Mountpoints FRANKFURT and FRANCE (same 4Char Station ID) and WETTZELL lead to the generation of RINEX files FRAN*_KFURT.*, FRAN*_CE.*, and WETT*.*. The header part of these files would be overwritten by the content of existing skeleton files named FRAN_KFURT.skl, FRAN_CE.skl, and WETT.skl if 'RINEX skeleton extension' is set to 'skl'.
@@ -260,5 +260,5 @@
B - 6.4 Get Table
-Hit button 'Get Table' to download the sourcetable from the NTRIP broadcaster. Pay attention to data fields 'format' and 'format-details'. Have in mind that BNC can only decode and convert streams that come in RTCM 2.x, RTCM 3, or RTIGS format. RTCM 2.x streams must contain message types 18 and 19 while RTCM 3 streams must contain message types 1001 or 1003, better 1003 or 1004, see data field 'format-details' for available message types and their repetition rates in brackets. Select your streams line by line, use +Shift and +Ctrl when necessary. +Hit button 'Get Table' to download the sourcetable from the NTRIP broadcaster. Pay attention to data fields 'format' and 'format-details'. Have in mind that BNC can only decode and convert streams that come in RTCM 2.x, RTCM 3, or RTIGS format. RTCM 2.x streams must contain message types 18 and 19 while RTCM 3 streams must contain message types 1001 or 1003, better 1003 or 1004 (GPS), 1009, or 1010, better 1011 or 1012 (GLONASS), see data field 'format-details' for available message types and their repetition rates in brackets. Select your streams line by line, use +Shift and +Ctrl when necessary.
@@ -269,16 +269,16 @@
B - 6.5 Delete Mountpoints
-To delete a stream shown under 'Mountpoints' in the main window select it by mouse click and hit 'Delete Mountpoints'. For simultaneous deletion of several streams single them out through using +Shift and +Ctrl.
+To delete a stream shown under 'Mountpoints' in the main window select it by mouse click and hit 'Delete Mountpoints'. For simultaneous deletion of several streams highlight them using +Shift and +Ctrl.B - 6.6 Edit Mountpoints
-BNC automatically selects one out of several internal decoders for a stream based on its 'format' and 'format-details' as given in the sourcetable. It may happen that you need to overrule the automated decoder selection because of sourcetable setup deficiencies. Therefore BNC allows to edit the decoder string (double-click) for each stream shown under 'Mountpoints'. Accepted decoder strings allowed to be introduced are 'RTCM_2.x', 'RTCM_3', and 'RTIGS'. +BNC automatically selects one out of several internal decoders for a stream based on its 'format' and 'format-details' as given in the sourcetable. It may happen that you need to overrule the automated decoder selection because of sourcetable setup deficiencies. Therefore BNC allows to edit (double-click) the decoder string for each stream shown under 'Mountpoints'. Accepted decoder strings allowed to be introduced are 'RTCM_2.x', 'RTCM_3', and 'RTIGS'.
-B - 7. Log File - optional
--BNC comments its activities in the 'Log file' section on the main windows. Comments can be saved and concatenated in a file when entering a full path for 'Log file'. Information is given about the communication between BNC and the NTRIP broadcaster as well as about problems that occur concerning communication link, stream availability, stream delay, stream conversion etc. Default value for 'Log file' is an empty option field, meaning that BNC comments are not saved in a file. +
B - 7. Log - optional
++BNC comments its activities in the 'Log' section on the main windows. Comments can be saved and concatenated in a file when entering the full path for 'Log' file. Information is given about the communication between BNC and the NTRIP broadcaster as well as about problems that may occur concerning communication link, stream availability, stream delay, stream conversion etc. Default value for 'Log' is an empty option field, meaning that BNC comments are not saved in a file.
@@ -286,5 +286,5 @@B - 8. Start
-Hit 'Start' to start retrieving, decoding, and converting GNSS data streams in real-time. +Hit 'Start' to start retrieving, decoding, and converting GNSS data streams in real-time. Note that 'Start' generally forces BNC to begin with fresh RINEX files and thus overwrite already existing files when necessary.
@@ -298,8 +298,8 @@B - 10. No Window - optional
-You can use BNC in batch mode with the command line option -nw. BNC then runs in 'no window' mode, reading options from the configuration file ${HOME}/.config/BKG/BNC_NTRIP_Client.conf (Unix/Linux) or from the registers (Windows). -
--Note that the self-explaining contents of the configuration file or the Windows registers can easily be edited. +You can use BNC on all systems in batch mode with the command line option -nw. BNC then runs in 'no window' mode, reading options from the configuration file ${HOME}/.config/BKG/BNC_NTRIP_Client.conf (Unix/Linux) or from the register BKC_NTRIP_Client (Windows). +
++Note that the self-explaining contents of the configuration file or the Windows register can easily be edited. Terminate BNC running in 'no window' mode on Windows systems using the Windows Task Manager.
@@ -308,11 +308,14 @@
- -The connection to an NTRIP broadcaster may break or a stream requested may be temporarily unavailable. Furthermore, a connection is interpreted by BNC to be broken if no data is coming in for a period of 20 seconds. When this happens, a reconnect is tried with decreasing frequency. BNC first tries to reconnect with ~1 second delay, if unsuccessful, tries again in ~2 seconds from the last attempt, if still unsuccessful tries with ~4 seconds from the last attempt etc. Each attempt doubles the delay from the previous attempt. The maximum delay between attempts is limited to ~128 seconds. The reconnection process is documented in 'Log file'. +The connection to an NTRIP broadcaster may break or a stream requested may be temporarily unavailable. Furthermore, a connection is interpreted by BNC to be broken if no data is coming in for a period of 20 seconds. When this happens, a reconnect is tried with decreasing frequency. BNC first tries to reconnect with ~1 second delay, if unsuccessful, tries again in ~2 seconds from the last attempt, if still unsuccessful tries with ~4 seconds from the last attempt etc. Each attempt doubles the delay from the previous attempt. The maximum delay between attempts is limited to ~128 seconds. The reconnection process is documented in the 'Log' file.
- -So far BNC only handles GPS data while ignoring GLONASS and Galileo observations. Furthermore, its function is limited today to processing L1, L2, P1, and P2 observations only. -
-- -Concerning RTCM Version 2.x, BNC handles only message types 18 and 19. Concerning RTCM Version 3, BNC handles only message types 1001, 1002, 1003, and 1004. +So far BNC only handles GPS and GLONASS data while ignoring Galileo. Furthermore, its function is limited today to processing C1, P1, P2, L1, and L2 observations only. +
+- +Due to a limitation of the RTIGS format and transport protocol, streams coming in that format so far only carry GPS data. +
+- +Concerning RTCM Version 2.x, BNC handles only message types 18 and 19. Concerning RTCM Version 3, BNC handles only message types 1001, 1002, 1003, 1004, 1009, 1010, 1011, and 1012.
- @@ -441,5 +444,5 @@
F - 2.1 RTCM Version 2.x
-Transmitting GNSS carrier phase data can be done through RTCM Version 2.x messages. Messages that may be of interest here are types 1, 2, 3, 6, 9, 16,18/19, 20/21, and 22. +Transmitting GNSS carrier phase data can be done through RTCM Version 2.x messages. Note that only RTCM Version 2.3 includes GLONASS data. Messages that may be of interest here are of type 1, 2, 3, 6, 9, 16,18/19, 20/21, and 22.
@@ -503,5 +506,5 @@F - 3. RTIGS
-RTIGS stands for a data format and transport protocol for GPS observations. It has been defined by the Real-Time IGS Working Group (RTIGS WG). Its definition is based on the SOC format. Every RTIGS record has one of the following numbers: +RTIGS stands for a data format and transport protocol for GPS observations (no GLONASS). It has been defined by the Real-Time IGS Working Group (RTIGS WG). Its definition is based on the SOC format. Every RTIGS record has one of the following numbers:
@@ -557,5 +560,5 @@
F - 3.1 SOC
-The SOC format has been designed in July 1999 by the Jet Propulsion Laboratory (JPL) and the California Institute of Technology (CalTech) to transport 1Hz GPS data with minimal bandwidth over the open Internet. SOC follows the 'little-endian' byte order meaning that the low-order byte of a number is stored in memory at the lowest address, and the high-order byte at the highest address. (The little end comes first.) Because the transport layer is UDP, the format does not include sync bits, a checksum or cyclic redundancy checksum (CRC). SOC allows to transport the GPS observable CA, P1, P2, L1, and L2, efficiently compressed down to 14 bytes with 1 mm range resolution and 0.02 mm phase resolution. SOC contains epochs for cycle slips, a stand-alone time-tag per epoch, a minimum representation of the receiver's clock solution, 3 SNR numbers, a unique site id, a modulo 12 hour sequence number and flags for receiver type and GPS health. SOC's simple structure comprises an 8 byte header, a 9 byte overhead for timetag, number of gps, etc., plus 21 data bytes per gps. +The SOC format has been designed in July 1999 by the Jet Propulsion Laboratory (JPL) and the California Institute of Technology (CalTech) to transport 1Hz GPS data (no GLONASS) with minimal bandwidth over the open Internet. SOC follows the 'little-endian' byte order meaning that the low-order byte of a number is stored in memory at the lowest address, and the high-order byte at the highest address. (The little end comes first.) Because the transport layer is UDP, the format does not include sync bits, a checksum or cyclic redundancy checksum (CRC). SOC allows to transport the GPS observable CA, P1, P2, L1, and L2, efficiently compressed down to 14 bytes with 1 mm range resolution and 0.02 mm phase resolution. SOC contains epochs for cycle slips, a stand-alone time-tag per epoch, a minimum representation of the receiver's clock solution, 3 SNR numbers, a unique site id, a modulo 12 hour sequence number and flags for receiver type and GPS health. SOC's simple structure comprises an 8 byte header, a 9 byte overhead for timetag, number of gps, etc., plus 21 data bytes per gps.