+The usual handling of BNC is that you first select a number of streams from NTRIP broadcasters ('Add Streams'). Any stream configured to BNC shows up on the 'Streams' canvas in the middle of BNC's main window. You then go through BNC's various tabs to select a combination of processing options before you start the program ('Start'). Records of BNC's activities are shown in the 'Log' canvas on the bottom of the main window. +
+All options for running BNC on Unix/Linux/Mac systems are saved in file ${HOME}/.config/BKG/BKG_NTRIP_Client.conf, see annexed 'Configuration File' example. On Windows systems options are saved in register BKG_NTRIP_Client. The self-explaining contents of the configuration file or the Windows register can easily be edited. Some options can be changed on-the-fly.
@@ -79,6 +82,7 @@ 3.4.1. Logfile-Records of BNC's activities are shown in the Log section on the bottom of the main window. These logs can be saved into a file when a valid path is specified in the 'Log (full path)' field. The message log covers the communication status between BNC and the NTRIP broadcaster as well as problems that may occur in the communication link, stream availability, stream delay, stream conversion etc. All times are given in UTC. The default value for 'Log (full path)' is an empty option field, meaning that BNC logs will not saved into a file. +Records of BNC's activities are shown in the 'Log' canvas on the bottom of the main window. These logs can be saved into a file when a valid path is specified in the 'Log (full path)' field. The message log covers the communication status between BNC and the NTRIP broadcaster as well as problems that may occur in the communication link, stream availability, stream delay, stream conversion etc. All times are given in UTC. The default value for 'Log (full path)' is an empty option field, meaning that BNC logs will not saved into a file.
@@ -191,10 +203,18 @@ -3.4.3 Reread Configuration - optional
3.4.3 Reread Configuration - optional
When operating BNC online in 'no window' mode (command line option -nw), some configuration options can nevertheless be changed on-the-fly without interrupting the running process. For that you force the program to reread parts of its configuration in pre-defined intervals. Select '1 min', '1 hour', or '1 day' to let BNC reread on-the-fly changeable configuration options every full minute, hour, or day. This lets in between edited options become effective without interrupting uninvolved threads. See annexed section 'Configuration File' for a Unix/Linux/Mac configuration file example and a list of on-the-fly changeable options.
- + ++You may like to auto-start BNC at startup time in window mode with preassigned configuration options. This may be required i.e. immediately after booting your system. Tick 'Auto start' to supersede the usage of the 'Start' button. Make sure that you maintain a link to BNC for that in your Autostart directory (Windows systems) or call BNC in a script below directory /etc/init.d (Unix/Linux/Mac systems). +
++ See BNC's command line option -nw for an auto-start of BNC in 'no window' mode. +
+ +Observations will be converted to RINEX if they come in either RTCM Version 2.x, RTCM Version 3.x, or RTIGS format. BNC's RINEX Observation files generally contain C1, C2, P1, P2, L1, L2, S1, and S2 observations. In case an observation is unavailable, its value is set to zero '0.000'. Note that the 'RINEX TYPE' field in the RINEX Observation file header is always set to 'M(MIXED)' even if the file does not contain any GLONASS or SABAS data. @@ -203,5 +223,5 @@
-RINEX file names are derived by BNC from the first 4 characters of the corresponding mountpoint (4Char Station ID). For example, data from mountpoints FRANKFURT and WETTZELL will have hourly RINEX Observation files named
+RINEX file names are derived by BNC from the first 4 characters of the corresponding stream's mountpoint (4Char Station ID). For example, data from mountpoints FRANKFURT and WETTZELL will have hourly RINEX Observation files named
FRAN{ddd}{h}.{yy}O
@@ -312,5 +332,5 @@
Broadcast ephemeris can be saved as RINEX Navigation files when received via RTCM Version 3.x as message types 1019 (GPS) and 1020 (GLONASS) or via RTIGS records type 300. The file name convention follows the details given in section 'RINEX File Names' except that the first four characters are 'BRDC' and the last character is @@ -347,5 +367,81 @@
- + ++
+RTCM is in the process of developing new Version 3 messages to transport satellite clock and orbit corrections in real-time. Based on the latest available proposal, the following premature messages currently under discussion have been implemented in BNC: ++RTCM Version 3 streams carrying these messages may be used i.e. to support real-time Precise Point Positioning (PPP) applications. +
++When using clocks from Broadcast Ephemeris (with or without corrections) and clocks from SP3 files in the same application, it is important to understand that Broadcast Ephemeris clocks - according to the Interface Control Documents (ICD) - are corrected for the 2nd-order relativistic effect whereas clocks from SP3 files are not. The 2nd-order relativistic effect is a priodic time correction defined as -2 (R * V) / c^2 and includes the scalar product of satallite position and velocity divided by the speed of light raised to the second power. +
+ + ++Specify a directory for saving Ephemeris Corrections in files. If the specified directory does not exist, BNC will not create Ephemeris Correction files. Default value for Ephemeris Corrections 'Directory' is an empty option field, meaning that no Ephemeris Correction files will be created. +
++The file name convention for Ephemeris Correction files follows the convention for RINEX files except for the last character of the file name suffix which is set to "C". +
+ +3.7.2 Interval - mandatory if 'Directory' is set
+Select the length of the Ephemeris Correction files. The default value is 1 day. +
+ + ++BNC can output epoch by epoch synchronized Ephemeris Corrections in ASCII format on your local host (IP 127.0.0.1) through an IP 'Port'. Specify an IP port number to activate this function. The default is an empty option field, meaning that no Ephemeris Correction output via IP port is generated. +
++The source code for BNC comes with an example perl script 'test_bnc_eph.pl' that allows you to read BNC's Ephemeris Corrections from the IP port. In case of a stream carrying message types 4056 and 4057, the script produces ASCII records containing the following set of parameters: +
++
+The following is an example output from two RTCM Version 3 streams (CLCK1 and CLCK4) containing message types 4056 and 4057: +
+... +1490 115710.0 R17 18 -1.903 2.348 -1.343 -1.403 CLCK1 +1490 115710.0 R10 18 -4.131 2.416 -0.646 -1.054 CLCK1 +1490 115710.0 G27 97 5.291 1.201 -1.964 0.821 CLCK4 +1490 115710.0 G26 14 -11.247 1.003 -1.168 0.074 CLCK4 +... +1490 115711.0 R17 18 -1.902 2.349 -1.342 -1.403 CLCK1 +1490 115711.0 R10 18 -4.131 2.415 -0.647 -1.052 CLCK1 +1490 115711.0 G27 97 5.288 1.200 -1.964 0.820 CLCK4 +1490 115711.0 G26 14 -11.246 1.004 -1.168 0.074 CLCK4 +... ++ + +
3.7.4 Wait for Full Epoch - mandatory if 'Port' is set
+When feeding a real-time GNSS engine waiting epoch by epoch for synchronized Ephemeris Corrections, BNC drops (only concering IP port output) whatever is received later than 'Wait for full epoch' seconds. A value of 2 to 5 seconds could be an appropriate choice for that, depending on the latency of the incoming Ephemeris Corrections stream and the delay acceptable by your application. A message such as "COCK1: Correction overaged by 5 sec" shows up in BNC's logfile if 'Wait for full epoch' is exceeded. +
+ +BNC can generate synchronized or unsynchronized observations epoch by epoch from all stations and satellites to feed a real-time GNSS engine. The output can be produced in a binary format through an IP port and/or a plain ASCII format to save the observations in a local file. It comprises the following observations where available:
@@ -357,5 +453,5 @@ -3.7.1 Port (synchronized) - optional
3.8.1 Port (synchronized) - optional
BNC can produce synchronized observations in binary format on your local host (IP 127.0.0.1) through an IP 'Port'. Specify an IP port number here to activate this function. The default is an empty option field, meaning that no binary output is generated.
@@ -409,8 +505,8 @@-Note that any socket connection of an application to BNC's synchronized observations 'Port' is recorded in the Log section on the bottom of the main window together with a connection counter, leading to log records like 'New Connection # 1'. -
- -3.7.2 Wait for Full Epoch - mandatory if 'Port (synchronized)' is set
3.8.2 Wait for Full Epoch - mandatory if 'Port (synchronized)' is set
When feeding a real-time GNSS engine waiting for synchronized input epoch by epoch, BNC drops whatever is received later than 'Wait for full epoch' seconds. A value of 3 to 5 seconds could be an appropriate choice for that, depending on the latency of the incoming streams and the delay acceptable for your real-time GNSS product. Default value for 'Wait for full epoch' is 5 seconds. @@ -420,5 +516,5 @@
-3.7.3 Port (unsynchronized) - optional
3.8.3 Port (unsynchronized) - optional
-Note that any socket connection of an application to BNC's unsynchronized observations 'Port' is recorded in the Log section on the bottom of the main window together with a connection counter, leading to log records like 'New Connection # 1'. -
- - - +Note that any socket connection of an application to BNC's unsynchronized observations 'Port' is recorded in the 'Log' canvas on the bottom of the main window together with a connection counter, leading to log records like 'New Connection # 1'. + + + +Specifies the full path to a 'File' where synchronized or unsynchronized observations are saved in plain ASCII format. The default value is an empty option field, meaning that no ASCII output file is created. @@ -439,86 +535,64 @@
-3.7.5 Sampling - mandatory if 'File' or 'Port' is set
3.8.5 Sampling - mandatory if 'File' or 'Port' is set
Select the observation output sampling interval in seconds. A value of zero '0' tells BNC to send/store all received epochs. This is the default value. -
- -
--
-RTCM is in the process of developing new Version 3 messages to transport satellite clock and orbit corrections in real-time. Based on the latest available proposal, the following premature messages currently under discussion have been implemented in BNC: --RTCM Version 3 streams carrying these messages may be used i.e. to support real-time Precise Point Positioning (PPP) applications. -
--When using clocks from Broadcast Ephemeris (with or without corrections) and clocks from SP3 files in the same application, it is important to understand that Broadcast Ephemeris clocks - according to the Interface Control Documents (ICD) - are corrected for the 2nd-order relativistic effect whereas clocks from SP3 files are not. The 2nd-order relativistic effect is a priodic time correction defined as -2 (R * V) / c^2 and includes the scalar product of satallite position and velocity divided by the speed of light raised to the second power. -
- - --Specify a directory for saving Ephemeris Corrections in files. If the specified directory does not exist, BNC will not create Ephemeris Correction files. Default value for Ephemeris Corrections 'Directory' is an empty option field, meaning that no Ephemeris Correction files will be created. -
--The file name convention for Ephemeris Correction files follows the convention for RINEX files except for the last character of the file name suffix which is set to "C". -
- -3.8.2 Interval - mandatory if 'Directory' is set
-Select the length of the Ephemeris Correction files. The default value is 1 day. -
- - --BNC can output epoch by epoch synchronized Ephemeris Corrections in ASCII format on your local host (IP 127.0.0.1) through an IP 'Port'. Specify an IP port number to activate this function. The default is an empty option field, meaning that no Ephemeris Correction output via IP port is generated. -
--The source code for BNC comes with an example perl script 'test_bnc_eph.pl' that allows you to read BNC's Ephemeris Corrections from the IP port. In case of a stream carrying message types 4056 and 4057, the script produces ASCII records containing the following set of parameters: -
--
-The following is an example output from two RTCM Version 3 streams (CLCK1 and CLCK4) containing message types 4056 and 4057: +
+ + ++You may use BNC to feed a serial connected device like an GNSS rover. For that one of the incoming streams can be forwarded to a serial port. +
+ + ++Enter a 'Mountpoint' to forward its corresponding stream to a serial connected device. +
++When selecting the serial communication options listed below, make sure that you pick those confiured to the serial connected device. +
+ +3.9.2 Port Name - mandatory if 'Mountpoint' is set
+Enter the serial 'Port name' selected on your host for communication with the serial connected device. Valid port names are +
-... -1490 115710.0 R17 18 -1.903 2.348 -1.343 -1.403 CLCK1 -1490 115710.0 R10 18 -4.131 2.416 -0.646 -1.054 CLCK1 -1490 115710.0 G27 97 5.291 1.201 -1.964 0.821 CLCK4 -1490 115710.0 G26 14 -11.247 1.003 -1.168 0.074 CLCK4 -... -1490 115711.0 R17 18 -1.902 2.349 -1.342 -1.403 CLCK1 -1490 115711.0 R10 18 -4.131 2.415 -0.647 -1.052 CLCK1 -1490 115711.0 G27 97 5.288 1.200 -1.964 0.820 CLCK4 -1490 115711.0 G26 14 -11.246 1.004 -1.168 0.074 CLCK4 -... +Windows: COM1, COM2 +Linux: /dev/ttyS0, /dev/ttyS1 +FreeBSD: /dev/ttyd0, /dev/ttyd1 +Digital Unix: /dev/tty01, /dev/tty02 +HP-UX: /dev/tty1p0, /dev/tty2p0 +SGI/IRIX: /dev/ttyf1, /dev/ttyf2 +SunOS/Solaris: /dev/ttya, /dev/ttyb- - -
3.8.4 Wait for Full Epoch - mandatory if 'Port' is set
-When feeding a real-time GNSS engine waiting epoch by epoch for synchronized Ephemeris Corrections, BNC drops (only concering IP port output) whatever is received later than 'Wait for full epoch' seconds. A value of 2 to 5 seconds could be an appropriate choice for that, depending on the latency of the incoming Ephemeris Corrections stream and the delay acceptable by your application. A message such as "COCK1: Correction overaged by 5 sec" shows up in BNC's logfile if 'Wait for full epoch' is exceeded. -
- - + +3.9.3 Baud Rate - mandatory if 'Mountpoint' is set
+Select a 'Baud rate' for the serial link. Note that using a high baud rate is recommended. +
+ +3.9.4 Parity - mandatory if 'Mountpoint' is set
+Select the 'Parity' for the serial link. Note that parity is often set to 'NONE'. +
+ +3.9.5 Data Bits - mandatory if 'Mountpoint' is set
+Select the number of 'Data bits' for the serial link. Note that often '8' data bits are used. +
+ +3.9.6 Stop Bits - mandatory if 'Mountpoint' is set
+Select the number of 'Stop bits' for the serial link. Note that often '1' stop bit is used. +
+ + ++Tick 'Auto NMEA' to forward NMEA-GGA messages (or any other message) coming from your serial connected device to the NTRIP brodacaster.
++This option replaces BNC's simulation of an initial NMEA-GGA message based on approximate latitude/longitude from the broadcaster's source-table. Note that sending valid NMEA-GGA strings (simulated or coming from your serial connected device) to the NTRIP broadcaster is required for receiving virtual reference station (VRS) streams. +
+ +@@ -532,13 +606,13 @@
-Outage and corruption events are reported in the Log file/section. They can also be passed on as parameters to a shell script or batch file to generate an advisory note to BNC operator or affected stream providers. This functionality lets users utilise BNC as a real-time performance monitor and alarm system for a network of GNSS reference stations. -
- - +Outage and corruption events are reported in the 'Log' file/canvas. They can also be passed on as parameters to a shell script or batch file to generate an advisory note to BNC operator or affected stream providers. This functionality lets users utilise BNC as a real-time performance monitor and alarm system for a network of GNSS reference stations. + + +BNC can collect all returns (success or failure) coming from a decoder within a certain short time span to then decide whether a stream has an outage or its content is corrupted. This procedure needs a rough a priory estimate of the expected observation rate of the incoming streams.
An empty option field (default) means that you don't want an explicit information from BNC about stream outages and incoming streams that can not be decoded and that the special procedure for handling of corrupted streams is by-passed (decoding attempt will never get paused).
-3.9.2 Failure Threshold - optional
3.10.2 Failure Threshold - optional
Event 'Begin_Failure' will be reported if no data is received continuously for longer than the 'Failure threshold' time. Similarly, event 'Begin_Corrupted' will be reported when corrupted data is detected by the decoder continuously for longer than this 'Failure threshold' time. The default value is set to 15 minutes and is recommended so not to innundate user with too many event reports. @@ -548,5 +622,5 @@
-3.9.3 Recovery Threshold - optional
3.10.3 Recovery Threshold - optional
Once a 'Begin_Failure' or 'Begin_Corrupted' event has been reported, BNC will check for when the stream again becomes available or uncorrupted. Event 'End_Failure' or 'End_Corrupted' will be reported as soon as valid observations are again detected continuously throughout the 'Recovery threshold' time span. The default value is set to 5 minutes and is recommended so not to innundate users with too many event reports. @@ -556,5 +630,5 @@
- +In case of a corrupted stream, the decoding process can be paused and decodings are then attempted again at decreasing rate. BNC will first attempt to decode again after a 30 second lag and if unsuccessful, make another attempt within 60 seconds after the previous attempt. If it is still unsuccessful, it will make another attempt to decode within 120 seconds after the previous attempt and so on. Each decoding attempt doubles the wait time since the previous attempt. The maximum wait time between attempts is limited to 960 seconds. Tick 'Pause' to activate this function. Note that it is only effective if an 'Observation rate' is specified. @@ -564,7 +638,7 @@
- --As mentioned previously, BNC can trigger a shell script or a batch file to be executed when one of the events described are reported. This script can be used to email an advisory note to network operator or stream providers. To enable this feature, specify the full path to the script or batch file in the 'Script' field. The affected mountpoint and type of event reported ('Begin_Outage', 'End_Outage', 'Begin_Corrupted' or 'End_Corrupted') will then be passed on to the script as command line parameters (%1 and %2 on Windows systems or $1 and $2 on Unix/Linux/Mac systems) together with date and time information. +
++As mentioned previously, BNC can trigger a shell script or a batch file to be executed when one of the events described are reported. This script can be used to email an advisory note to network operator or stream providers. To enable this feature, specify the full path to the script or batch file in the 'Script' field. The affected stream's mountpoint and type of event reported ('Begin_Outage', 'End_Outage', 'Begin_Corrupted' or 'End_Corrupted') will then be passed on to the script as command line parameters (%1 and %2 on Windows systems or $1 and $2 on Unix/Linux/Mac systems) together with date and time information.
@@ -593,15 +667,15 @@
- +This section describes a number of miscellaneous options which can be applied for a single stream (mountpoint) or for all configured streams.
- +Specify a mountpoint to apply one or several of the 'Miscellaneous' options to the corresponding stream. Enter 'ALL' if you want to apply these options to all configured streams. An empty option field (default) means that you don't want BNC to apply any of these options.
- +BNC can average latencies per stream over a certain period of GPS time, the 'Performance log' interval. Mean latencies are calculated from the individual latencies of at most one (first incoming) observation or correction to Broadcast Ephemeris per second. Note that computing correct latencies requires the clock of the host computer to be properly synchronized. @@ -621,5 +695,5 @@
-Latencies of observations or corrections to Broadcast Ephemeris and statistical information can be recorded in the Log file/section at the end of each 'Performance log' interval. A typical output from a 1 hour 'Performance log' interval would be: +Latencies of observations or corrections to Broadcast Ephemeris and statistical information can be recorded in the 'Log' file/canvas at the end of each 'Performance log' interval. A typical output from a 1 hour 'Performance log' interval would be:
@@ -631,7 +705,7 @@ - --When configuring a GNSS receiver for RTCM stream generation, the setup interface may not provide details about RTCM message types. As reliable information concerning stream contents should be available i.e. for NTRIP broadcaster operators to maintain the broadcaster's sourcetable, BNC allows to scan RTCM streams for incoming message types and printout some of the contained meta-data. The idea for this option arose from 'InspectRTCM', a comprehensive stream analyzing tool written by D. Stoecker. +
++When configuring a GNSS receiver for RTCM stream generation, the setup interface may not provide details about RTCM message types. As reliable information concerning stream contents should be available i.e. for NTRIP broadcaster operators to maintain the broadcaster's source-table, BNC allows to scan RTCM streams for incoming message types and printout some of the contained meta-data. The idea for this option arose from 'InspectRTCM', a comprehensive stream analyzing tool written by D. Stoecker.
@@ -657,10 +731,10 @@
- --Each stream on an NTRIP broadcaster is defined using a unique source ID called mountpoint. An NTRIP client like BNC access the desired data stream by referring to its mountpoint. Information about mountpoints is available through the source-table maintained by the NTRIP broadcaster. Note that mountpoints could show up in BNC more than once when retrieving streams from several NTRIP broadcasters. -
- -Streams selected for retrieval are listed under the 'Mountpoints' section on BNC's main window. The list provides the following information extracted from source-table(s) produced by the NTRIP broadcasters: + ++Each stream on an NTRIP broadcaster is defined using a unique source ID called mountpoint. An NTRIP client like BNC access the desired data stream by referring to its mountpoint. Information about streams and their mountpoints is available through the source-table maintained by the NTRIP broadcaster. Note that mountpoints could show up in BNC more than once when retrieving streams from several NTRIP broadcasters. +
+ +Streams selected for retrieval are listed under the 'Streams' canvas section on BNC's main window. The list provides the following information extracted from source-table(s) produced by the NTRIP broadcasters:
-Button 'Add Mountpoints' opens a window that allows user to select data streams from an NTRIP broadcaster according to their mountpoints. -
- -3.11.2 Broadcaster Host and Port - required
+Button 'Add Streams' opens a window that allows user to select data streams from an NTRIP broadcaster according to their mountpoints. +
+ +3.12.2 Broadcaster Host and Port - mandatory
Enter the NTRIP broadcaster host IP and port number. http://www.rtcm-ntrip.org/home provides information about known NTRIP broadcaster installations. Note that EUREF and IGS operate NTRIP broadcasters at http://www.euref-ip.net/home and http://www.igs-ip.net/home.
-3.11.3 Broadcaster User and Password - required for protected streams
3.12.3 Broadcaster User and Password - mandatory for protected streams
Some streams on NTRIP broadcasters may be restricted. Enter a valid 'User' ID and 'Password' for access to protected streams. Accounts are usually provided per NTRIP broadcaster through a registration procedure. Register through http://igs.bkg.bund.de/index_ntrip_reg.htm for access to protected streams on www.euref-ip.net and www.igs-ip.net.
- +Use the 'Get Table' button to download the source-table from the NTRIP broadcaster. Pay attention to data fields 'format' and 'format-details'. Keep in mind that BNC can only decode and convert streams that come in RTCM Version 2.x, RTCM Version 3.x, or RTIGS format. RTCM Version 2.x streams must contain message types 18 and 19 or 20 and 21 while RTCM Version 3.x streams must contain GPS or SBAS message types 1002 or 1004 and may contain GLONASS message types 1010 or 1012, see data field 'format-details' for available message types and their repetition rates in brackets. Note that in order to produce RINEX Navigation files RTCM Version 3.x streams containing message types 1019 (GPS) and 1020 (GLONASS) are required. Select your streams line by line, use +Shift and +Ctrl when necessary.
-The contents of data field 'nmea' tells you whether a stream retrieval needs to be initiated by BNC through sending an NMEA-GGA message carrying position coordinates (virtual reference station). -
--Hit 'OK' to return to the main window. If you wish you can click on 'Add Mountpoints' and repeat the process again to retrieve mountpoints from different casters. -
- - --To remove a stream from the 'Mountpoints' list in the main window, highlight it by clicking on it and hit the 'Delete Mountpoints' button. You can also remove multiple mountpoints simultaneously by highlighting them using +Shift and +Ctrl.
- - +The contents of data field 'nmea' tells you whether a stream retrieval needs to be initiated by BNC through sending an NMEA-GGA message carrying approximate position coordinates (virtual reference station). + ++Hit 'OK' to return to the main window. If you wish you can click on 'Add Streams' and repeat the process again to retrieve streams from different casters. +
+ + ++To remove a stream from the 'Streams' canvas in the main window, highlight it by clicking on it and hit the 'Delete Streams' button. You can also remove multiple streams simultaneously by highlighting them using +Shift and +Ctrl.
+ +3.11.7 Reconfigure Mountpoints On-the-fly
-The mountpoints selection can be changed on-the-fly without interrupting uninvolved threads in the running BNC process. -
--Window mode: Hit 'Save & Activate Options' while BNC is in window mode and already processing data to let changes of your mountpoints selection immediately become effective. -
-No window mode: When operating BNC online in 'no window' mode (command line option -nw), you force BNC to reread its 'mountPoints' configuration option in pre-defined intervals. Select '1 min', '1 hour', or '1 day' as 'Reread configuration' option to reread the 'mountpoints' option every full minute, hour, or day. This lets a 'mountPoints' option edited in between in the configuration file or Windows register become effective without terminating uninvolved threads. See annexed section 'Configuration File' for a Unix/Linux/Mac configuration file example and a list of other on-the-fly changeable options. -
- - +3.12.7 Reconfigure Streams On-the-fly
+The streams selection can be changed on-the-fly without interrupting uninvolved threads in the running BNC process. +
++Window mode: Hit 'Save & Activate Options' while BNC is in window mode and already processing data to let changes of your streams selection immediately become effective. +
+No window mode: When operating BNC online in 'no window' mode (command line option -nw), you force BNC to reread its 'mountPoints' configuration option in pre-defined intervals. Select '1 min', '1 hour', or '1 day' as 'Reread configuration' option to reread the 'mountPoints' option every full minute, hour, or day. This lets a 'mountPoints' option edited in between in the configuration file or Windows register become effective without terminating uninvolved threads. See annexed section 'Configuration File' for a Unix/Linux/Mac configuration file example and a list of other on-the-fly changeable options. +
+ +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 which might overwrite existing files when necessary unless the option 'Append files' is ticked.
- +Hit the 'Stop' button in order to stop BNC.
- +Command line options are available to run BNC in 'no window' mode or let it read data from a file in offline mode. BNC will then use processing options from the configuration file (Unix/Linux/Mac) or from the register BKG_NTRIP_Client (Windows). Note that the self-explaining contents of the configuration file or the Windows register can easily be edited.
-3.14.1 No Window Mode - optional
3.15.1 No Window Mode - optional
Apart from its regular windows mode, BNC can be started on all systems as a background/batch job with command line option '-nw'. BNC will then run in 'no window' mode, using processing options from its configuration file. Terminate BNC using Windows Task Manager when running it in 'no window' mode on Windows systems. @@ -754,5 +828,5 @@
-3.14.2 Offline Mode - optional
3.15.2 Offline Mode - optional
Although BNC is primarily a real-time online tool, it can be run in offline mode to read data from a file for post processing purposes. Enter the following four command line options for that: @@ -862,5 +936,5 @@