-BNC includes the following GNU GPL software components: +BNC includes the following GNU GPL software component:
- RTCM 2 decoder, written by Oliver Montenbruck, German Space Operations Center, DLR, Oberpfaffenhofen, Germany; -
- RTCM 3 decoder for conventional and MSM observation messages and a RTCM 3 encoder & decoder for SSR messages, both written for BKG by Dirk Stöcker, Alberding GmbH, Schönefeld, Germany.
-BNC can be used in different contexts with varying data flows. Typical real-time communication follows the Ntrip protocol over TCP/IP (probably via SSL), RTSP/RTP or UDP, plain TCP/IP protocol, or serial communication links. Stream contents could be observations, ephemeris, satellite orbit/clock products or NMEA sentences. +BNC can be used in different contexts with varying data flows. Typical real-time communication follows the Ntrip protocol over TCP/IP (probably via SSL), RTSP/RTP or UDP, plain TCP/IP protocol, or serial communication links. Stream content could be observations, ephemeris, satellite orbit/clock products or NMEA sentences.
@@ -567,5 +566,5 @@
- To simulate real-time observation situations for debugging purposes; -
- For Post Processing purposes. +
- For post processing purposes.
-The default filename 'BNC.bnc' can be changed and the file contents can easily be edited. On graphical user interfaces it is possible to Drag & Drop a configuration file icon to start BNC (not on Mac OS X systems). It is also possible to start and configure BNC via command line. Some configuration options can be changed on-the-fly. See annexed 'Command Line Help' for a complete set of configuration options. +The default filename 'BNC.bnc' can be changed and the file content can easily be edited. On graphical user interfaces it is possible to Drag & Drop a configuration file icon to start BNC (not on Mac OS X systems). It is also possible to start and configure BNC via command line. Some configuration options can be changed on-the-fly. See annexed 'Command Line Help' for a complete set of configuration options.
@@ -636,5 +635,5 @@ Configuration options are usually specified using GUI input fields (1) after launching BNC. When hitting the 'Start' button, configuration options are transferred one level down to become BNC's active configuration (2), allowing the program to begin its operation. Pushing the 'Stop' button ends data processing so that the user can finally terminate BNC through 'File'->'Quit'->'Save Options' which saves processing options in a configuration file to disk (3). It is important to understand that:-
-
- Active configuration options (2) are independent from GUI input fields and configuration file contents. +
- Active configuration options (2) are independent from GUI input fields and configuration file content.
- Hence changing configuration options at GUI level (1) while BNC is already processing data does not influence a running job.
- Editing configuration options at disk level (3) while BNC is already processing data does also not influence a running job. However, there are two exceptions which force BNC to update certain active options on-the-fly: @@ -785,13 +784,13 @@ configuration reads RTCM Version 3 observations, Broadcast Corrections and a Broadcast Ephemeris stream. Positions are saved in NMEA format on disc. -Positions are also output through IP port for real-time visualization with -tools like RTKPLOT. Positions are also saved in the logfile. +They are also output through IP port for real-time visualization with tools +like RTKPLOT. Positions are also saved in the logfile.
- File 'PPPPostProc.bnc'
-The purpose of this configuration is Precise Point Positioning in Post -Processing mode. BNC reads RINEX Version 3 Observation and 3 Navigation files -and a Broadcast Corrections file. PPP processing options are set to support -the Quick-Start mode. The output is saved in a specific Post Processing +The purpose of this configuration is Precise Point Positioning in post +processing mode. BNC reads RINEX Version 3 Observation and 3 Navigation files +and a Broadcast Correction file. PPP processing options are set to support +the Quick-Start mode. The output is saved in a specific post processing logfile and contains coordinates derived over time following the implemented PPP filter algorithm. @@ -818,7 +817,7 @@ - File 'SaveSp3.bnc'
The purpose of this configuration is to produce SP3 files from a Broadcast -Ephemeris stream and a Broadcast Corrections stream. The Broadcast Corrections +Ephemeris stream and a Broadcast Correction stream. The Broadcast Correction stream is formally introduced in BNC's 'Combine Corrections' table. Note that -producing SP3 requires an ANTEX file because SP3 file contents should be +producing SP3 requires an ANTEX file because SP3 file content should be referred to CoM. - File 'CompareSp3.bnc'
The purpose of this configuration is to compare two SP3 files to calculate -RMS values for orbit and clock differences. GPS satellite G05 and GLONASS +RMS values from orbit and clock differences. GPS satellite G05 and GLONASS satellite R18 are excluded from this comparison. Comparison results are saved in a logfile. @@ -879,5 +878,5 @@ - File 'Empty.bnc'
The purpose of this example is to provide an empty configuration file for BNC -which only contains the default settings. +which only contains default settings.
@@ -898,5 +897,5 @@
- -BNC's 'Get Table' function only shows the STR records of a source-table. You can use an Internet browser to download the full source-table contents of any Ntrip Broadcaster by simply entering its URL in the form of http://host:port. Data field number 8 in the NET records may provide information about where to register for an Ntrip Broadcaster account. +BNC's 'Get Table' function only shows the STR records of a source-table. You can use an Internet browser to download the full source-table content of any Ntrip Broadcaster by simply entering its URL in the form of http://host:port. Data field number 8 in the NET records may provide information about where to register for an Ntrip Broadcaster account.
-
@@ -916,5 +915,5 @@
-To cope with an increasing number of transmitting GNSS reference stations, the Federal Agency for Cartography and Geodesy (BKG) together with the Informatik Centrum Dortmund (ICD) in Germany developed a streaming protocol for satellite navigation data called 'Networked Transport of RTCM via Internet Protocol' (Ntrip). The protocol was built on top of the HTTP standard and included the provision of meta data describing the stream contents. Any stream could now be globally transmitted over just one IP port: HTTP port 80. Stream availability and content details became part of the transport protocol. The concept was first published in 2003 (Weber et al. 2003) and based on three software components, namely an NtripServer pushing data from a reference station to an NtripCaster and an NtripClient pulling data from the stream splitting caster to support a rover receiver. (Note that from a socket-programmers perspective NtripServer and NtripClient both act as clients; only the NtripCaster operates as socket-server.) Ntrip could essentially benefit from Internet Radio developments. It was the ICECAST multimedia server which provided the bases for BKG's 'Professional Ntrip Broadcaster' with software published first in 2003 and of course again as Open Source under GPL. +To cope with an increasing number of transmitting GNSS reference stations, the Federal Agency for Cartography and Geodesy (BKG) together with the Informatik Centrum Dortmund (ICD) in Germany developed a streaming protocol for satellite navigation data called 'Networked Transport of RTCM via Internet Protocol' (Ntrip). The protocol was built on top of the HTTP standard and included the provision of meta data describing the stream content. Any stream could now be globally transmitted over just one IP port: HTTP port 80. Stream availability and content details became part of the transport protocol. The concept was first published in 2003 (Weber et al. 2003) and based on three software components, namely an NtripServer pushing data from a reference station to an NtripCaster and an NtripClient pulling data from the stream splitting caster to support a rover receiver. (Note that from a socket-programmers perspective NtripServer and NtripClient both act as clients; only the NtripCaster operates as socket-server.) Ntrip could essentially benefit from Internet Radio developments. It was the ICECAST multimedia server which provided the bases for BKG's 'Professional Ntrip Broadcaster' with software published first in 2003 and of course again as Open Source under GPL.
@@ -937,5 +936,5 @@
2. Settings Details
-The following chapters describe how to set BNC program options. They explain the 'Top Menu Bar', the 'Settings Canvas' with the processing options, the contents of the 'Streams Canvas' and 'Logging Canvas', and the 'Bottom Menu Bar'. +The following chapters describe how to set BNC program options. They explain the 'Top Menu Bar', the 'Settings Canvas' with the processing options, the content of the 'Streams Canvas' and 'Logging Canvas', and the 'Bottom Menu Bar'.
@@ -1022,5 +1021,5 @@
-The following is an example for the contents of a logfile written by BNC when operated in Single Point Positioning (SPP) mode: +The following is an example for the content of a logfile written by BNC when operated in Single Point Positioning (SPP) mode:
@@ -1079,5 +1078,5 @@
2.3.5 Raw Output File - optional
-BNC can save all data coming in through various streams in one daily file. The information is recorded in the specified 'Raw output file' in the received order and format. This feature allows a BNC user to run the PPP option offline with observations, Broadcast Corrections, and Broadcast Ephemeris being read from a previously saved file. It supports the offline repetition of a real-time situation for debugging purposes and it is not meant for Post Processing. +BNC can save all data coming in through various streams in one daily file. The information is recorded in the specified 'Raw output file' in the received order and format. This feature allows a BNC user to run the PPP option offline with observations, Broadcast Corrections, and Broadcast Ephemeris being read from a previously saved file. It supports the offline repetition of a real-time situation for debugging purposes and it is not meant for post processing.
@@ -1114,5 +1113,5 @@
-The screenshot below shows an example setup of BNC when converting streams to RINEX. Streams are coming from various Ntrip Broadcasters as well as from a serial communication link. Specifying a decoder string 'ZERO' means to not convert the affected stream but save its contents as received. The 'SSL Error' recorded in the 'Log' tab is caused by the fact that observation stream downloads from IGS and MGEX Broadcasters initiate the download of RINEX skeleton files from a HTTPS (TLS/SSL) website and BNC has been configured in this example to ignore SSL errors as shown in the preceding 'Network' panel screenshot. +The screenshot below shows an example setup of BNC when converting streams to RINEX. Streams are coming from various Ntrip Broadcasters as well as from a serial communication link. Specifying a decoder string 'ZERO' means to not convert the affected stream but save its content as received. The 'SSL Error' recorded in the 'Log' tab is caused by the fact that observation stream downloads from IGS and MGEX Broadcasters initiate the download of RINEX skeleton files from a HTTPS (TLS/SSL) website and BNC has been configured in this example to ignore SSL errors as shown in the preceding 'Network' panel screenshot.
@@ -1198,5 +1197,5 @@-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. +Sometimes public RINEX header skeleton files are not available, their content 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.
@@ -1214,5 +1213,5 @@ Note the following regulations regarding personal RINEX header skeleton files:
-
-
- If such a file exists in the 'RINEX directory', the corresponding public RINEX header skeleton file is ignored. The RINEX header is generated solely from the contents of the personal skeleton. +
- If such a file exists in the 'RINEX directory', the corresponding public RINEX header skeleton file is ignored. The RINEX header is generated solely from the content of the personal skeleton.
- Personal skeletons should contain a complete first header record of type
- RINEX VERSION / TYPE
@@ -1294,5 +1293,5 @@
GNSS observation data are generally hold available within BNC according to attributes as defined in RINEX Version 3. These attributes describe the tracking mode or channel when generating the observation signals. Capital letters specifying signal generation attributes are A, B, C, D, I, L, M, N, P, Q, S, W, X, Y, and Z, see RINEX Version 3 documentation. Although RINEX Version 3 with its signal generation attributes is the internal default processing format for BNC, there are two applications where the program is explicitly required to produce data in RINEX Version 2 format:
- When saving the contents of incoming observation streams in RINEX Version 2 files as described in this section. +
- When saving the content of incoming observation streams in RINEX Version 2 files as described in this section.
- When editing or concatenating RINEX 3 files to save them in Version 2 format, see section on 'RINEX Editing & QC'.
- File Editing and concatenation @@ -1418,6 +1417,6 @@
- Select 'Edit/Concatenate' if you want to edit RINEX file contents according to options specified under 'Set Edit Options' or if you want to concatenate several RINEX files. -
- Select 'Analyze' if you are interested in a quality check of your RINEX file contents. +
- Select 'Edit/Concatenate' if you want to edit RINEX file content according to options specified under 'Set Edit Options' or if you want to concatenate several RINEX files. +
- Select 'Analyze' if you are interested in a quality check of your RINEX file content.
-
-
Default is an empty check box, meaning to still use filenames following the RINEX Version 2 standard although the file contents is saved in RINEX Version 3 format. +
Default is an empty check box, meaning to still use filenames following the RINEX Version 2 standard although the file content is saved in RINEX Version 3 format.
@@ -1392,5 +1391,5 @@ Tick check box 'Version 3 filenames' to let BNC create so-called extended filenames following the RINEX Version 3 standard. -Default is an empty check box, meaning to still use filenames following the RINEX Version 2 standard although the file contents is saved in RINEX Version 3 format. +
Default is an empty check box, meaning to still use filenames following the RINEX Version 2 standard although the file content is saved in RINEX Version 3 format.
@@ -1400,5 +1399,5 @@2.6 RINEX Editing & QC
-Besides stream conversion from RTCM to RINEX, BNC allows editing RINEX files or concatenate their contents. RINEX Observation and Navigation files can be handled. BNC can also carry out a RINEX file Quality Check. In summary and besides Stream Translation this functionality in BNC covers +Besides stream conversion from RTCM to RINEX, BNC allows editing RINEX files or concatenate their content. RINEX Observation and Navigation files can be handled. BNC can also carry out a RINEX file Quality Check. In summary and besides Stream Translation this functionality in BNC covers
Select an action. Options are 'Edit/Concatenate' and 'Analyze'.
-
-
-When specifying several input files BNC will concatenate their contents. In case of RINEX Observation input files with different observation type header records, BNC will output only one specific set of adjusted observation type records in the RINEX header which fits to the whole file contents. +When specifying several input files BNC will concatenate their contents. In case of RINEX Observation input files with different observation type header records, BNC will output only one specific set of adjusted observation type records in the RINEX header which fits to the whole file content.
@@ -1446,5 +1445,5 @@
-Note that logfiles from analyzing RINEX files may become quite large. Hence BNC provides an option 'Summary only' to limit this logfile contents to some essential information in case 'Action' is set to 'Analyze'. The following is an example for a RINEX quality check analysis logfile: +Note that logfiles from analyzing RINEX files may become quite large. Hence BNC provides an option 'Summary only' to limit this logfile content to some essential information in case 'Action' is set to 'Analyze'. The following is an example for a RINEX quality check analysis logfile:
QC Format Version : 1.0 @@ -1707,5 +1706,5 @@
-You can specify a list of observation codes in field 'Use Obs. Types' to limit the output file contents to specific observation codes. GNSS system characters in that list are followed by a colon and a two or three characters observation code. A two characters observation code would mean that all available tracking modes of the affected observation type and frequency will be accepted as part of the RINEX output file. Observation codes are separated by a blank character. Default is an empty option field, meaning that any input observation code will become part of the RINEX output file. +You can specify a list of observation codes in field 'Use Obs. Types' to limit the output file content to specific observation codes. GNSS system characters in that list are followed by a colon and a two or three characters observation code. A two characters observation code would mean that all available tracking modes of the affected observation type and frequency will be accepted as part of the RINEX output file. Observation codes are separated by a blank character. Default is an empty option field, meaning that any input observation code will become part of the RINEX output file.
@@ -1715,5 +1714,5 @@-If you specify a 'New' but no 'Old' marker/antenna/receiver name, the corresponding data field in the emerging new RINEX Observation file will be filled accordingly. If you in addition specify an 'Old' marker/antenna/receiver name, the corresponding data field in the emerging new RINEX Observation file will only be filled accordingly where 'Old' specifications match existing file contents. +If you specify a 'New' but no 'Old' marker/antenna/receiver name, the corresponding data field in the emerging new RINEX Observation file will be filled accordingly. If you in addition specify an 'Old' marker/antenna/receiver name, the corresponding data field in the emerging new RINEX Observation file will only be filled accordingly where 'Old' specifications match existing file content.
@@ -1738,5 +1737,5 @@2.6.8 Command Line, No Window - optional
-BNC applies options from the configuration file but allows updating every one of them on the command line while the contents of the configuration file remains unchanged, see section on 'Command Line Options'. Note the following syntax for Command Line Interface (CLI) options: +BNC applies options from the configuration file but allows updating every one of them on the command line while the content of the configuration file remains unchanged, see section on 'Command Line Options'. Note the following syntax for Command Line Interface (CLI) options:
@@ -1987,9 +1986,9 @@
-The 'Epoch Record' of a Broadcast Corrections block -
- --The leading 'Epoch Record' of each block in a Broadcast Corrections file contains 11 parameters. Example: +The 'Epoch Record' of a Broadcast Correction block +
+ ++The leading 'Epoch Record' of each block in a Broadcast Correction file contains 11 parameters. Example:
@@ -2202,5 +2201,5 @@
2.8.1 Directory, ASCII - optional
-Specify a directory for saving Broadcast Corrections in files. If the specified directory does not exist, BNC will not create Broadcast Correction files. Default value for Broadcast Corrections 'Directory' is an empty option field, meaning that no Broadcast Correction files will be created. +Specify a directory for saving Broadcast Corrections in files. If the specified directory does not exist, BNC will not create Broadcast Correction files. Default value for Broadcast Correction 'Directory' is an empty option field, meaning that no Broadcast Correction files will be created.
@@ -2402,5 +2401,5 @@2.10 Serial Output
-You may use BNC to feed a serial connected device like a GNSS receiver. For that an incoming stream can be forwarded to a serial port. Depending on the stream contents the receiver may use it for Differential GNSS, Precise Point Positioning or any other purpose supported by its firmware. +You may use BNC to feed a serial connected device like a GNSS receiver. For that an incoming stream can be forwarded to a serial port. Depending on the stream content the receiver may use it for Differential GNSS, Precise Point Positioning or any other purpose supported by its firmware.
@@ -2613,5 +2612,5 @@
2.12.3 Scan RTCM - optional
-When configuring a GNSS receiver for RTCM stream generation, the firmware's setup interface may not provide details about RTCM message types and observation 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. Contained observation types are also printed because such information is required a priori for the conversion of RTCM Version 3 MSM streams to RINEX Version 3 files. The idea for this option arose from 'inspectRTCM', a comprehensive stream analyzing tool written by D. Stöcker. +When configuring a GNSS receiver for RTCM stream generation, the firmware's setup interface may not provide details about RTCM message types and observation types. As reliable information concerning stream content 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. Contained observation types are also printed because such information is required a priori for the conversion of RTCM Version 3 MSM streams to RINEX Version 3 files. The idea for this option arose from 'inspectRTCM', a comprehensive stream analyzing tool written by D. Stöcker.
@@ -2648,5 +2647,5 @@
2.12.4 Port - optional
-BNC can output streams related to the above specified 'Mountpoint' through a TCP/IP port of your local host. Enter a port number to activate this function. The stream contents remains untouched. BNC does not decode or reformat the data. +BNC can output streams related to the above specified 'Mountpoint' through a TCP/IP port of your local host. Enter a port number to activate this function. The stream content remains untouched. BNC does not decode or reformat the data.
@@ -2721,5 +2720,5 @@
-Specifying only a RINEX Observation and a RINEX Navigation file and no Broadcast Corrections file leads BNC to a 'Single Point Positioning' (SPP) solution. +Specifying only a RINEX Observation and a RINEX Navigation file and no Broadcast Correction file leads BNC to a 'Single Point Positioning' (SPP) solution.
Debugging
@@ -2753,5 +2752,5 @@2.13.1.5 Corrections File - optional if 'Data source' is set to 'RINEX Files'
-Specify a Broadcast 'Corrections file' as saved beforehand using BNC. The file contents is basically the ASCII representation of a RTCM Version 3 Broadcast Correction (SSR) stream. +Specify a Broadcast 'Corrections file' as saved beforehand using BNC. The file content is basically the ASCII representation of a RTCM Version 3 Broadcast Correction (SSR) stream.
@@ -2796,5 +2795,5 @@
-The following is an example contents for a 'Coordinates' file. Here each record describes the mountpoint of a stream available from the global IGS real-time reference station network. A priori coordinates are followed by North/East/Up eccentricity components of the ARP +The following is the content of an example 'Coordinates' file. Here each record describes the mountpoint of a stream available from the global IGS real-time reference station network. A priori coordinates are followed by North/East/Up eccentricity components of the ARP followed by the antenna name and radome in use.
@@ -3073,5 +3072,5 @@-You can specify a 'SNX TRO Directory' for saving SINEX Troposphere files on disk, see https://igscb.jpl.nasa.gov/igscb/data/format/sinex_tropo.txt for a documentation of the file format. Note that receiver type information for these files must be provided through the coordinates file described in section 'Coordinates'. The following is an example for a troposphere file contents: +You can specify a 'SNX TRO Directory' for saving SINEX Troposphere files on disk, see https://igscb.jpl.nasa.gov/igscb/data/format/sinex_tropo.txt for a documentation of the file format. Note that receiver type information for these files must be provided through the coordinates file described in section 'Coordinates'. The following is an example for a troposphere file content:
@@ -3233,5 +3232,5 @@
@@ -827,6 +826,6 @@ The purpose of this configuration is to produce SP3 files from a Broadcast Ephemeris stream and a stream carrying ETRF2000 Broadcast Corrections. The -Broadcast Corrections stream is formally introduced in BNC's 'Combine -Corrections' table. This leads to an SP3 file containing orbits referred also +Broadcast Correction stream is formally introduced in BNC's 'Combine +Corrections' table. This leads to a SP3 file containing orbits referred also to ETRF2000. Pulling in addition observations from a reference station at precisely known ETRF2000 position allows comparing an 'INTERNAL' PPP solution @@ -840,7 +839,7 @@ Broadcast Ephemeris. BNC converts the orbits and clocks into Broadcast Corrections and encodes them in RTCM Version 3 SSR messages to upload them to -an Ntrip Broadcaster. The Broadcast Corrections stream is referred to satellite -Antenna Phase Center (APC) and IGS08. Orbits are saved on disk in SP3 format -and clocks in Clock RINEX format. +an Ntrip Broadcaster. The Broadcast Correction stream is referred to satellite +Antenna Phase Center (APC) and reference system IGS08. Orbits are saved on disk +in SP3 format and clocks in Clock RINEX format.
@@ -848,9 +847,9 @@ The purpose of this configuration is to pull several streams carrying Broadcast Corrections and a Broadcast Ephemeris stream from an Ntrip Broadcaster to -produce a combined Broadcast Corrections stream. BNC encodes the combination +produce a combined Broadcast Correction stream. BNC encodes the combination product in RTCM Version 3 SSR messages and uploads that to an Ntrip -Broadcaster. The Broadcast Corrections stream is not referred to satellite -Center of Mass (CoM). It is referred to IGS08. Orbits are saved in SP3 format -and clocks in Clock RINEX format. +Broadcaster. The Broadcast Correction stream is not referred to satellite +Center of Mass (CoM). Its reference system is IGS08. Orbits are saved in SP3 +format and clocks in Clock RINEX format.
@@ -866,11 +865,11 @@ The purpose of this configuration is to pull a number of streams from reference stations to get hold of contained Broadcast Ephemeris messages. These are -encoded then in a RTCM Version 3 stream which only provides Broadcast Ephemeris -with an update rate of 5 seconds. +encoded then in a RTCM Version 3 stream with the sole purpose of providing +Broadcast Ephemeris with an update rate of 5 seconds.
Note that most geodetic GPS receivers support the observation of both, code and phase data. Hence specifying 'P3&L3' would be a good choice for GPS when processing data from such a receiver. If multi-GNSS data processing is your intention, make sure your receiver supports GLONASS and/or Galileo and/or BDS observations besides GPS. Note also that the Broadcast Corrections stream or file which is required for PPP also supports all the systems you have in mind. +
Note that most geodetic GPS receivers support the observation of both, code and phase data. Hence specifying 'P3&L3' would be a good choice for GPS when processing data from such a receiver. If multi-GNSS data processing is your intention, make sure your receiver supports GLONASS and/or Galileo and/or BDS observations besides GPS. Note also that the Broadcast Correction stream or file which is required for PPP also supports all the systems you have in mind.
Specifying 'no' means that you don't at all want BNC to use observations from the affected GNSS system. @@ -3451,5 +3450,5 @@
2.14.1 Combine Corrections Table - optional
-Hit the 'Add Row' button, double click on the 'Mountpoint' field, enter a Broadcast Corrections mountpoint from the 'Streams' section and hit Enter. Then double click on the 'AC Name' field to enter your choice of an abbreviation for the Analysis Center (AC) providing the Antenna Phase Center (APC) related stream. Finally, double click on the 'Weight' field to enter a weight to be applied to this stream in the combination. +Hit the 'Add Row' button, double click on the 'Mountpoint' field, enter a Broadcast Correction mountpoint from the 'Streams' section and hit Enter. Then double click on the 'AC Name' field to enter your choice of an abbreviation for the Analysis Center (AC) providing the Antenna Phase Center (APC) related stream. Finally, double click on the 'Weight' field to enter a weight to be applied to this stream in the combination.
@@ -3476,8 +3475,8 @@
Figure 29: BNC uploading the combined Broadcast Corrections stream.
+Figure 29: BNC uploading the combined Broadcast Correction stream.
Figure 30: 'INTERNAL' PPP with BNC using combined Broadcast Corrections stream.
+Figure 30: 'INTERNAL' PPP with BNC using combined Broadcast Correction stream.