Changeset 7710 in ntrip

Timestamp:

Jan 25, 2016, 12:43:49 PM (9 years ago)

Author:

weber

Message:

Documentation completed

File:

• trunk/BNC/src/bnchelp.html (modified) (84 diffs)

trunk/BNC/src/bnchelp.html

@@ -243 +243 @@
 <tr><td>17</td><td>Example for pulling, saving and output of Broadcast Corrections using BNC</td><td>2.8.3</td></tr>
 <tr><td>18</td><td>Synchronized BNC output via IP port to feed a GNSS real-time engine</td><td>2.9</td></tr>
-<tr><td>19</td><td>Flowcharts, BNC forwarding a stream to a serial connected receiver; sending NMEA sentences is mandatory for VRS streams</td><td>2.10</td></tr>
-<tr><td>20</td><td>BNC pulling a VRS stream to feed a serial connected RTK rover</td><td>2.10</td></tr>
+<tr><td>19</td><td>Flowcharts, BNC forwarding a stream to a serially connected receiver; sending NMEA sentences is mandatory for VRS streams</td><td>2.10</td></tr>
+<tr><td>20</td><td>BNC pulling a VRS stream to feed a serially connected RTK rover</td><td>2.10</td></tr>
 <tr><td>21</td><td>RTCM message numbers, latencies and observation types logged by BNC</td><td>2.12</td></tr>
 <tr><td>22</td><td>Real-time Precise Point Positioning with BNC, PPP Panel 1</td><td>2.13.1</td></tr>
@@ -364 +364 @@
 
 <p>
-Promoting Open RTCM Standards for streaming GNSS data over the Internet has been a major aspect in developing BNC as Open Source real-time software. Basically, the tool enables the test, validation and further evolution of new RTCM messages for precise satellite navigation. With high-level source code at hand, it also allows university education to catch up with comprehensive state-of-the-art positioning and potentially contribute fresh ideas which are free from any licensing.
+Promoting Open RTCM Standards for streaming GNSS data over the Internet has been a major aspect in developing BNC as Open Source real-time software. Basically, the tool enables the test, validation and further evolution of new RTCM messages for precise satellite navigation. With high-level source code at hand, it also allows university education to catch up with comprehensive state-of-the-art positioning and potentially contributes fresh ideas which are free from any licensing.
 </p>
 
@@ -435 +435 @@
 
 <p>
-Note that BNC allows to by-pass decoding and conversion algorithms for incoming streams, leave whatever is received untouched to save it in files or output it through local TCP/IP port.
+Note that BNC allows to by-pass decoding and conversion algorithms for incoming streams, leaves whatever is received untouched to save it in files or output it through local TCP/IP port.
 </p>
 
 <p><h4>1.2 <a name="introSystem">Supported GNSS</h4></p>
 <p>
-BNC is permanently completed to finally support all existing GNSS systems throughout all features of the program. The table below shows in detail which GNSS systems are so far supported by particular applications when using the latest BNC version. Application areas named here are:
+BNC is permanently completed to finally support all existing GNSS systems throughout all features of the program. The table below shows in detail which GNSS systems are supported so far by particular applications when using the latest BNC version. Application areas named here are:
 <ul>
 <li>Decoding of RTCM or RTNET streams</li>
@@ -449 +449 @@
 <li>Combining/merging SSR or ephemeris messages from various real-time sources</li>
 </ul>
-The table mentions if a message implementation in BNC could so far only be based on a 'RTCM Proposal'.
+The table indicates if a message implementation in BNC could so far only be based on a 'RTCM Proposal'.
 </p>
 <p><u>Table 1:</u> Status of RTCM Version 3 message implementations in BNC supporting various GNSS systems</p>
@@ -538 +538 @@
 </p>
 <p>
-The first of the following figures shows a flow chart of BNC connected to a GNSS receiver providing observations via serial or TCP communication link for the purpose of Precise Point Positioning. The second figure shows the conversion of RTCM streams to RINEX files. The third figure shows a flow chart of BNC feeding a real-time GNSS engine which estimates precise orbits and clocks. BNC is used in this scenario to encode correctors to RTCM Version 3 and upload them to an Ntrip Broadcaster. The fourth figure shows BNC combining several Broadcast Correction streams to disseminate the combination product while saving results in SP3 and Clock RINEX files.
+The first of the following figures shows a flow chart of BNC connected to a GNSS receiver providing observations via serial or TCP communication link for the purpose of Precise Point Positioning. The second figure shows the conversion of RTCM streams to RINEX files. The third figure shows a flow chart of BNC feeding a real-time GNSS engine, which estimates precise orbits and clocks. BNC is used in this scenario to encode correctors to RTCM Version 3 and upload them to an Ntrip Broadcaster. The fourth figure shows BNC combining several Broadcast Correction streams to disseminate the combination product while saving results in SP3 and Clock RINEX files.
 </p>
 <p><img src="IMG/screenshot10.png"/></p>
@@ -608 +608 @@
 
 <p>
-<u>Linux Build:</u> Static library and shared library builds for BNC are provided for a selection of Linux distributions. Download the ZIP archive for a version which fits to your Linux system, unzip the archive and run the included BNC binary. A static build would be sufficient in case you <u>don't want</u> BNC to plot PPP results with Google Map (GM) or OpenStreetMap (OSM) maps in the background. GM/OSM usage requires BNC builds from shared libraries.
+<u>Linux Build:</u> Static library and shared library builds for BNC are provided for a selection of Linux distributions. Download the ZIP archive for a version which fits to your Linux system, unzip the archive and run the included BNC binary. A static build would be sufficient in case you <u>do not want</u> BNC to plot PPP results with Google Map (GM) or OpenStreetMap (OSM) maps in the background. GM/OSM usage requires BNC builds from shared libraries.
 </p>
 
@@ -625 +625 @@
 
 <p><b>Static versus Shared Libraries</b><br>
-You can produce static or shared builds of BNC. <u>Static</u> builds are sufficient in case you don't want BNC to produce track maps on top of Google Map (GM) or OpenStreetMap (OSM). GM/OSM usage would require the QtWebKit library which can only be part of BNC builds from <u>shared</u> Qt libraries. Hence, having a shared library Qt installation available is a precondition for producing a shared library build of BNC.
+You can produce static or shared builds of BNC. <u>Static</u> builds are sufficient in case you do not want BNC to produce track maps on top of Google Map (GM) or OpenStreetMap (OSM). GM/OSM usage would require the QtWebKit library which can only be part of BNC builds from <u>shared</u> Qt libraries. Hence, having a shared library Qt installation available is a precondition for producing a shared library build of BNC.
 </p>
 
@@ -706 +706 @@
 
 <p>
-Qt will be installed into directory /usr/local/Trolltech/Qt-4.8.5. To reconfigure, run 'gmake confclean' and 'configure'. Note that the '-prefix' option allows you to specify a directory for saving the Qt libraries. This ensures that you don't run into conflicts with other
+Qt will be installed into directory /usr/local/Trolltech/Qt-4.8.5. To reconfigure, run 'gmake confclean' and 'configure'. Note that the '-prefix' option allows you to specify a directory for saving the Qt libraries. This ensures that you do not run into conflicts with other
 Qt installations on your host. Note further that the following two lines<pre>
   export QTDIR="/usr/local/Trolltech/Qt-4.8.5"
@@ -794 +794 @@
 
 <p>
-BNC comes with a number of configuration examples which can be used on all operating systems. Copy the complete directory 'Example_Configs' which comes with the software to your disc. It includes sub-directories 'Input' and 'Output'. There are several ways to start BNC using one of the example configurations:
+BNC comes with a number of configuration examples, which can be used on all operating systems. Copy the complete directory 'Example_Configs' which comes with the software to your disc. It includes sub-directories 'Input' and 'Output'. There are several ways to start BNC using one of the example configurations:
 </p>
 <ul>
 <li>
-On graphical systems (except for Mac systems) you may use the computer mouse to 'drag' a configuration file icon and 'drop' it on top of BNC's program icon.
+On graphical systems (except for Mac systems), you may use the computer mouse to 'drag' a configuration file icon and 'drop' it on top of BNC's program icon.
 </li>
 <li>
@@ -831 +831 @@
 
 <p>
-Note that the account for an Ntrip Broadcaster is usually limited to pulling a specified maximum number of streams at the same time. As running some of the example configurations requires pulling several streams, it is suggested to make sure that you don't exceed your account's limits.
+Note that the account for an Ntrip Broadcaster is usually limited to pulling a specified maximum number of streams at the same time. As running some of the example configurations requires pulling several streams, it is suggested to make sure that you do not exceed your account's limits.
 </p>
 
@@ -892 +892 @@
 
 <li>File 'RTK.bnc'<br>
-Purpose: Feed a serial connected receiver with 
+Purpose: Feed a serially connected receiver with 
 observations from a nearby reference station for conventional RTK. The stream is 
 scanned for RTCM messages. Message type numbers and latencies of incoming 
@@ -1001 +1001 @@
 <li>File 'CombiPPP.bnc'<br>
 Purpose: This configuration equals the 'Combi.bnc' configuration. However, the combined 
-Broadcast Corrections are in addition used for an 'INTERNAL' PPP solutions 
+Broadcast Corrections are in addition used for an 'INTERNAL' PPP solution 
 based on observations from a static reference station with known precise 
 coordinates. This allows a continuous quality check of the combination product 
@@ -1023 +1023 @@
 <li>File 'Empty.bnc'<br>
 Purpose: Provide an empty example configuration file for
-BNC which only contains default settings.
+BNC, which only contains default settings.
 </li>
 
@@ -1061 +1061 @@
 </p>
 <p>
-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 and Honkala 2004, Weber et al. 2005a) and was 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 and Honkala 2004, Weber et al. 2005a) and was 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.
 </p>
 <p>
@@ -1067 +1067 @@
 </p>
 <p>
-With the advent of Ntrip as an open streaming standard, BKG's interest turned towards taking advantage from free real-time access to GNSS observations. International Associations such as the IAG Reference Frame Sub Commissions for Africa (AFREF), Asia & Pacific (APREF), Europe (EUREF), North America (NAREF) Latin America & Caribbean (SIRGAS), and the International GNSS Service (IGS) maintain continental or even global GNSS networks with the majority of modern receivers supporting Ntrip stream upload. Through operating BKG's NtripCaster software, these networks became extremely valuable sources of real-time GNSS information.  In 2005, this was the starting point for developing the 'BKG Ntrip Client' (BNC) as a multi-stream Open Source NtripClient which allows pulling hundreds of streams simultaneously from any number of NtripCaster installations world-wide. Decoding incoming RTCM streams and output observations epoch by epoch via IP port to feed a real-time GNSS network engine became BNC's first and foremost ability (Weber and Mervart 2009). Converting decoded streams to short high-rate RINEX files to assist near real-time applications became a welcome by-product right from the start of this development.
-</p>
-<p>
-Adding real-time Precise Point Positioning (PPP) support to BNC began in 2010 as an important completion in view of developing an Open RTCM Standard for that. According to the State Space Representation (SSR) model, new Version 3 messages are proposed to provide e.g. satellite orbit and clock corrections and ionospheric corrections as well as biases for code and phase data. The ultimate goal for SSR standardization is to reach centimeter level accuracy within seconds as an alternative to Network RTK methods such as VRS, FKP, and MAC. Because of interoperability aspects, an Open Standard in this area is of particular interest for clients. Regarding stand-alone PPP in BNC, it is worth mentioning that the program is not and can never be in competition with a receiver manufacturer's proprietary solution. Only software or services which are part of a receiver firmware could have the potential of becoming a thread for commercial interests. However, implementing or not implementing an Open PPP approach in a firmware is and will always remain a manufacturer's decision.
+With the advent of Ntrip as an open streaming standard, BKG's interest turned towards taking advantage from free real-time access to GNSS observations. International Associations such as the IAG Reference Frame Sub Commissions for Africa (AFREF), Asia & Pacific (APREF), Europe (EUREF), North America (NAREF) Latin America & Caribbean (SIRGAS), and the International GNSS Service (IGS) maintain continental or even global GNSS networks with the majority of modern receivers supporting Ntrip stream upload. Through operating BKG's NtripCaster software, these networks became extremely valuable sources of real-time GNSS information.  In 2005, this was the starting point for developing the 'BKG Ntrip Client' (BNC) as a multi-stream Open Source NtripClient that allows pulling hundreds of streams simultaneously from any number of NtripCaster installations world-wide. Decoding incoming RTCM streams and output observations epoch by epoch via IP port to feed a real-time GNSS network engine became BNC's first and foremost ability (Weber and Mervart 2009). Converting decoded streams to short high-rate RINEX files to assist near real-time applications became a welcome by-product right from the start of this development.
+</p>
+<p>
+Adding real-time Precise Point Positioning (PPP) support to BNC began in 2010 as an important completion in view of developing an Open RTCM Standard for that. According to the State Space Representation (SSR) model, new Version 3 messages are proposed to provide e.g. satellite orbit and clock corrections and ionospheric corrections as well as biases for code and phase data. The ultimate goal for SSR standardization is to reach centimeter level accuracy within seconds as an alternative to Network RTK methods such as VRS, FKP, and MAC. Because of interoperability aspects, an Open Standard in this area is of particular interest for clients. Regarding stand-alone PPP in BNC, it is worth mentioning that the program is not and can never be in competition with a receiver manufacturer's proprietary solution. Only software or services that are part of a receiver firmware could have the potential of becoming a thread for commercial interests. However, implementing or not implementing an Open PPP approach in a firmware is and will always remain a manufacturer's decision.
 </p>
 <p>
@@ -1135 +1135 @@
 <p><h4>2.2.1 <a name="proxy">Proxy - Usage in a protected LAN</h4></p>
 <p>
-If you are running BNC within a protected Local Area Network (LAN), you might need to use a proxy server to access the Internet. 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 the proxy server settings in your Internet browser or ask your network administrator.</p>
+If you are running BNC within a protected Local Area Network (LAN), you might need to use a proxy server to access the Internet. Enter your proxy server IP and port number in case one is operated in front of BNC. If you do not know the IP and port of your proxy server, check the proxy server settings in your Internet browser or ask your network administrator.</p>
 <p>
 Note that IP streaming is often not allowed in a LAN. In this case you need to ask your network administrator for an appropriate modification of the local security policy or for the installation of a TCP relay to the Ntrip Broadcasters. If this is not possible, you might need to run BNC outside your LAN on a host that has unobstructed connection to the Internet.
@@ -1154 +1154 @@
    No certificates could be verified
 </pre>
-Tick 'Ignore SSL authorization errors' if you generally trust the server and don't want to be bothered with this. Note that SSL communication is usually done over port 443.
+Tick 'Ignore SSL authorization errors' if you generally trust the server and do not want to be bothered with this. Note that SSL communication is usually done over port 443.
 </p>
 
@@ -1167 +1167 @@
 <p><h4>2.3.1 <a name="genlog">Logfile - optional</h4></p>
 <p>
-Records of BNC's activities are shown in the 'Log' tab on the bottom of the main window. These logs can be saved into a file when a valid path is specified in the 'Logfile (full path)' field. The logfile name will automatically be extended by a string '_YYMMDD' for the current date. This leads to series of daily logfiles when running BNC continuously for extended. Message logs cover 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 'Logfile (full path)' is an empty option field, meaning that BNC logs will not be saved into a file.
+Records of BNC's activities are shown in the 'Log' tab on the bottom of the main window. These logs can be saved into a file when a valid path is specified in the 'Logfile (full path)' field. The logfile name will automatically be extended by a string '_YYMMDD' for the current date. This leads to series of daily logfiles when running BNC continuously. Message logs cover 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 'Logfile (full path)' is an empty option field, meaning that BNC logs will not be saved into a file.
 </p>
 <p>
@@ -1200 +1200 @@
 <p><h4>2.3.3 <a name="genconf">Reread Configuration - optional</h4></p>
 <p>
-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 from the disk. 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. 
+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 from the disk. 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. 
 </p>
 
@@ -1247 +1247 @@
 </p>
 <p>
-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 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 'Skeleton Mandatory') and switch to a default selection of observation types when such file is not available or does not contain the required information. The following is the default selection of observation types specified for a RINEX Version 3 file:
+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 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 'Skeleton Mandatory') and switch to a default selection of observation types when such file is not available or does not contain the required information. The following is the default selection of observation types specified for a RINEX Version 3 file:
 </p>
 <pre>
@@ -1259 +1259 @@
 
 <p>
-Please note that RTCM Version 3 messages 1084 for GLONASS observations don't contain the channel numbers. However, these messages can only be converted to RINEX when you add messages which include the channel numbers. This could be done by means of an additional stream carrying 1087 GLONASS observation messages or an additional stream carrying 1020 GLONASS ephemeris messages. You could also consider setting up a streams which contains both, the 1084 and the 1020 messages.
+Please note that RTCM Version 3 messages 1084 for GLONASS observations do not contain the channel numbers. However, these messages can only be converted to RINEX when you add messages which include the channel numbers. This could be done by means of an additional stream carrying 1087 GLONASS observation messages or an additional stream carrying 1020 GLONASS ephemeris messages. You could also consider setting up a stream which contains both, the 1084 and the 1020 messages.
 </p>
 <p>
@@ -1343 +1343 @@
 <p><h4>2.4.5 <a name="rnxskl">Skeleton Extension - optional</h4></p>
 <p>
-Whenever BNC starts to generate 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 or HTTPS 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 <u>http://www.epncb.oma.be:80/stations/log/skl/brus.skl</u> for an example of a public RINEX header skeleton file for EPN station Brussels. Note that the download of RINEX skeleton files from HTTPS websites requires the exchange of client and/or server certificates. Clarify 'SSL' options offered through panel 'Network' for details.
-</p>
-<p>
-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.
+Whenever BNC starts to generate 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. An HTTP or HTTPS 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 <u>http://www.epncb.oma.be:80/stations/log/skl/brus.skl</u> for an example of a public RINEX header skeleton file for EPN station Brussels. Note that the download of RINEX skeleton files from HTTPS websites requires the exchange of client and/or server certificates. Clarify 'SSL' options offered through panel 'Network' for details.
+</p>
+<p>
+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.
 </p>
 <p>
@@ -1378 +1378 @@
 <br>- &nbsp; SYS / # / OBS TYPES (for RINEX Version 3 files, will be ignored when writing Version 2 files)</li>
 <li>They may contain any other optional complete header record as defined in the RINEX documentation.</li>
-<li>They should also contain an empty header records of type
+<li>They should also contain an empty header record of type
 <br>- &nbsp; # / TYPES OF OBSERV (only RINEX Version 2, will be ignored when writing RINEX Version 3 files)
 <br>BNC will include these lines in the final RINEX file header together with an additional
@@ -1445 +1445 @@
 <li>When editing or concatenating RINEX 3 files to save them in Version 2 format, see section on 'RINEX Editing & QC'.</li>
 </ol>
-As the Version 2 format ignores signal generation attributes, BNC is forced to somehow map RINEX Version 3 to RINEX Version 2 although this can't be done in one-to-one correspondence. Hence we introduce a 'Signal priority' list of attributes (characters, forming a string) for mapping Version 3 to Version 2.
+As the Version 2 format ignores signal generation attributes, BNC is forced to somehow map RINEX Version 3 to RINEX Version 2 although this cannot be done in one-to-one correspondence. Hence we introduce a 'Signal priority' list of attributes (characters, forming a string) for mapping Version 3 to Version 2.
 </p>
 <p>
@@ -1466 +1466 @@
 </p>
 <p>
-You may like to specify you own 'Signal priority' string(s) for producing RINEX Version 2 files. If you neither convert observation streams to RINEX Version 2 nor concatenate RINEX Version 3 to Version 2 files, then the 'Version 2' option is meaningless.
+You may like to specify your own 'Signal priority' string(s) for producing RINEX Version 2 files. If you neither convert observation streams to RINEX Version 2 nor concatenate RINEX Version 3 to Version 2 files, then the 'Version 2' option is meaningless.
 </p>
 
@@ -1475 +1475 @@
 
 <p>
-Note that it is possible to force a RTCM Version 2 stream to be saved in RINEX Version 3 file format. However, this is not recommended because such stream cannot be precisely mapped to RINEX Version 3 as the required information on tracking modes (observation attributes) is not part of RTCM Version 2.
+Note that it is possible to force an RTCM Version 2 stream to be saved in RINEX Version 3 file format. However, this is not recommended because such stream cannot be precisely mapped to RINEX Version 3 as the required information on tracking modes (observation attributes) is not part of RTCM Version 2.
 </p>
 
@@ -1533 +1533 @@
 </p>
 <p>
-Note that this does not concern the Broadcast Ephemeris output through IP port which is always in RINEX Version 3.03 format.
+Note that this does not concern the Broadcast Ephemeris output through IP port, which is always in RINEX Version 3.03 format.
 </p>
 
@@ -1577 +1577 @@
 </p>
 <p>
-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.
+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.
 </p>
 <p>
@@ -1594 +1594 @@
 
 <p>
-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:
+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:
 <pre>
 QC Format Version  : 1.0
@@ -1841 +1841 @@
 <p>
 <ul>
-<li>The RINEX Version 2 format ignores signal generation attributes. Therefore, when converting <u>RINEX Version 3 to Version 2</u> Observation files, BNC is forced to somehow map signals with attributes to signals without attributes although this can't be done in one-to-one correspondence. Hence we introduce a 'Version 2 Signal Priority' list of attributes (characters, forming a string) for mapping Version 3 to Version 2, see details in section 'RINEX Observations/Version 2'. The default 'Version 2 Signal Priority' list of observation attributes when mapping RINEX Version 3 to Version 2 is 'CWPX_?'. Signal priorities can be specified either as equal for all systems or system specific. The following are example priority strings:</li>
+<li>The RINEX Version 2 format ignores signal generation attributes. Therefore, when converting <u>RINEX Version 3 to Version 2</u> Observation files, BNC is forced to somehow map signals with attributes to signals without attributes although this cannot be done in one-to-one correspondence. Hence we introduce a 'Version 2 Signal Priority' list of attributes (characters, forming a string) for mapping Version 3 to Version 2, see details in section 'RINEX Observations/Version 2'. The default 'Version 2 Signal Priority' list of observation attributes when mapping RINEX Version 3 to Version 2 is 'CWPX_?'. Signal priorities can be specified either as equal for all systems or system specific. The following are example priority strings:</li>
 <ul>
 <li>CWPX_? (Same signal priorities valid for all systems)</li>
@@ -1969 +1969 @@
 <p><h4>2.7 <a name="sp3comp">SP3 Comparison</h4></p>
 <p>
-BNC allows to compare the contents of two files containing GNSS orbit and clock data in SP3 format. SP3 ASCII files basically contain a list of records over a certain period of time. Each record carries a time tag, the XYZ position of the satellite's Center of Mass at that time and the corresponding satellite clock value. Both SP3 files may contain some records for different epochs. If so then BNC only compares records for identical epochs. BNC accepts that a specific GNSS system or a specific satellite is only available from one of the SP3 files. Note that BNC does not interpolate orbits when comparing SP3 files. 
+BNC allows to compare the contents of two files containing GNSS orbit and clock data in SP3 format. SP3 ASCII files basically contain a list of records over a certain period of time. Each record carries a time tag, the XYZ position of the satellite's Center of Mass at that time and the corresponding satellite clock value. Both SP3 files may contain some records for different epochs. If so, then BNC only compares records for identical epochs. BNC accepts that a specific GNSS system or a specific satellite is only available from one of the SP3 files. Note that BNC does not interpolate orbits when comparing SP3 files. 
 </p>
 <p>
@@ -2085 +2085 @@
 </p>
 <p>
-An alternative to the observation space approach is the so-called 'sate space' approach. The principle here is to provide information on individual error sources. It can be called 'State Space Representation' (SSR). For a rover position, state space information concerning precise satellite clocks, orbits, ionosphere, troposphere et cetera can be converted into observation space and used to correct the rover observables for more accurate positioning. Alternatively, the state information can be used directly in the rover's processing or adjustment model.
+An alternative to the observation space approach is the so-called 'state space' approach. The principle here is to provide information on individual error sources. It can be called 'State Space Representation' (SSR). For a rover position, state space information concerning precise satellite clocks, orbits, ionosphere, troposphere et cetera can be converted into observation space and used to correct the rover observables for more accurate positioning. Alternatively, the state information can be used directly in the rover's processing or adjustment model.
 </p>
 <p>
@@ -2124 +2124 @@
 
 <p>
-The orbit and clock corrections do not include local effects like Ocean Loading, Solid Earth Tides or tropospheric delays. However, accurate single frequency applications can be correct for global ionospheric effects using so-call VTEC messages for global ionospheric state parameters.
-</p>
-
-<p>
-While we have a plain ASCII standard for saving Broadcast Ephemeris in RINEX Navigation files, we don't have an equivalent standard for corrections to Broadcast Ephemeris. Hence BNC saves Broadcast Correction files following its own format definition. The filename convention for Broadcast Correction files follows the convention for RINEX Version 2 files except for the last character of the filename suffix which is set to 'C'.
+The orbit and clock corrections do not include local effects like Ocean Loading, Solid Earth Tides or tropospheric delays. However, accurate single frequency applications can be corrected for global ionospheric effects using so-call VTEC messages for global ionospheric state parameters.
+</p>
+
+<p>
+While we have a plain ASCII standard for saving Broadcast Ephemeris in RINEX Navigation files, we do not have an equivalent standard for corrections to Broadcast Ephemeris. Hence, BNC saves Broadcast Correction files following its own format definition. The filename convention for Broadcast Correction files follows the convention for RINEX Version 2 files except for the last character of the filename suffix, which is set to 'C'.
 </p>
 
@@ -2449 +2449 @@
 
 <p>
-The following is an example for file and IP port output which presents observations from GPS, GLONASS, Galileo, BDS (BeiDou), QZSS, and SBAS satellites as collected through streams WTZR0, CUT07, and COCO0:
+The following is an example for file and IP port output, which presents observations from GPS, GLONASS, Galileo, BDS (BeiDou), QZSS, and SBAS satellites as collected through streams WTZR0, CUT07, and COCO0:
 <pre>
 > 1850 120556.0000000
@@ -2519 +2519 @@
 <p><h4>2.9.1 <a name="syncport">Port - optional</h4></p>
 <p>
-BNC can produce synchronized observations in ASCII format on your local host (IP 127.0.0.1) through an IP 'Port'. Synchronized means that BNC collects all observation data for a specific epoch which become available within a certain number of seconds (see 'Wait for Full Obs Epoch' option). It then - epoch by epoch - outputs whatever has been received. The output comes block-wise per stream. Specify an IP port number here to activate this function. The default is an empty option field, meaning that no binary synchronized output is generated.</p>
+BNC can produce synchronized observations in ASCII format on your local host (IP 127.0.0.1) through an IP 'Port'. Synchronized means that BNC collects all observation data for a specific epoch, which become available within a certain number of seconds (see 'Wait for Full Obs Epoch' option). It then - epoch by epoch - outputs whatever has been received. The output comes block-wise per stream. Specify an IP port number here to activate this function. The default is an empty option field, meaning that no binary synchronized output is generated.</p>
 </p>
 
@@ -2550 +2550 @@
 <p><h4>2.10 <a name="serial">Serial Output</h4></p>
 <p>
-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.
+You may use BNC to feed a serially 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.
 </p>
 <p>
@@ -2557 +2557 @@
 
 <p><img src="IMG/screenshot35.png"/></p>
-<p><u>Figure 19:</u> Flowcharts, BNC forwarding a stream to a serial connected receiver; sending NMEA sentences is mandatory for VRS streams</p>
-
-<p>
-The following figure shows the screenshot of an example situation where BNC pulls a VRS stream from an Ntrip Broadcaster to feed a serial connected RTK rover.
+<p><u>Figure 19:</u> Flowcharts, BNC forwarding a stream to a serially connected receiver; sending NMEA sentences is mandatory for VRS streams</p>
+
+<p>
+The following figure shows the screenshot of an example situation where BNC pulls a VRS stream from an Ntrip Broadcaster to feed a serially connected RTK rover.
 </p>
 
 <p><img src="IMG/screenshot11.png"/></p>
-<p><u>Figure 20:</u> BNC pulling a VRS stream to feed a serial connected RTK rover</p>
+<p><u>Figure 20:</u> BNC pulling a VRS stream to feed a serially connected RTK rover</p>
 
 <p><h4>2.10.1 <a name="sermount">Mountpoint - optional</h4></p>
 <p>
-Enter a 'Mountpoint' to forward its corresponding stream to a serial connected GNSS receiver.
-</p>
-<p>
-When selecting one of the serial communication options listed below, make sure that you pick those configured to the serial connected receiver.
+Enter a 'Mountpoint' to forward its corresponding stream to a serially connected GNSS receiver.
+</p>
+<p>
+When selecting one of the serial communication options listed below, make sure that you pick those configured to the serially connected receiver.
 </p>
 
 <p><h4>2.10.2 <a name="serport">Port Name - mandatory if 'Mountpoint' is set</h4></p>
 <p>
-Enter the serial 'Port name' selected on your host for communication with the serial connected receiver. Valid port names are
+Enter the serial 'Port name' selected on your host for communication with the serially connected receiver. Valid port names are
 </p>
 <pre>
@@ -2598 +2598 @@
 <p><h4>2.10.4 <a name="serflow">Flow Control - mandatory if 'Mountpoint' is set</h4></p>
 <p>
-Select a 'Flow control' for the serial output link. Note that your selection must equal the flow control configured to the serial connected device. Select 'OFF' if you don't know better.
+Select a 'Flow control' for the serial output link. Note that your selection must equal the flow control configured to the serially connected device. Select 'OFF' if you do not know better.
 </p>
 
@@ -2617 +2617 @@
 
 <p><h4>2.10.8 <a name="serauto">NMEA - mandatory if 'Mountpoint' is set</h4></p>
-<p>The 'NMEA' option supports the so-called 'Virtual Reference Station' (VRS) concept which requires the receiver to send approximate position information to the Ntrip Broadcaster. Select 'no' if you don't want BNC to forward or upload any NMEA sentence to the Ntrip broadcaster in support of VRS.
-</p>
-<p>Select 'Auto' to automatically forward NMEA sentences of type GGA from your serial connected receiver to the Ntrip broadcaster and/or save them in a file.
-</p>
-<p>Select 'Manual GPGGA' or 'Manual GNGGA' if you want BNC to produce and upload GPGGA or GNGGA NMEA sentences to the Ntrip broadcaster because your serial connected receiver doesn't generate them. A Talker ID 'GP' proceeding the GGA string stands for GPS solutions while a Talker ID 'GN' stands for multi-constellation solutions.
+<p>The 'NMEA' option supports the so-called 'Virtual Reference Station' (VRS) concept which requires the receiver to send approximate position information to the Ntrip Broadcaster. Select 'no' if you do not want BNC to forward or upload any NMEA sentence to the Ntrip broadcaster in support of VRS.
+</p>
+<p>Select 'Auto' to automatically forward NMEA sentences of type GGA from your serially connected receiver to the Ntrip broadcaster and/or save them in a file.
+</p>
+<p>Select 'Manual GPGGA' or 'Manual GNGGA' if you want BNC to produce and upload GPGGA or GNGGA NMEA sentences to the Ntrip broadcaster because your serially connected receiver does not generate them. A Talker ID 'GP' proceeding the GGA string stands for GPS solutions while a Talker ID 'GN' stands for multi-constellation solutions.
 </p>
 <p>Note that selecting 'Auto' or 'Manual' works only for VRS streams which show up under the 'Streams' canvas on BNC's main window with 'nmea' stream attribute set to 'yes'. This attribute is either extracted from the Ntrip broadcaster's source-table or introduced by the user through editing the BNC configuration file.
@@ -2627 +2627 @@
 
 <p><h4>2.10.9 <a name="serfile">File - optional if 'NMEA' is set to 'Auto'</h4></p>
-<p>Specify the full path to a file where NMEA sentences coming from your serial connected receiver are saved. Default is an empty option field, meaning that no NMEA sentences will be saved on disk.
+<p>Specify the full path to a file where NMEA sentences coming from your serially connected receiver are saved. Default is an empty option field, meaning that no NMEA sentences will be saved on disk.
 </p>
 <p><h4>2.10.10 <a name="serheight">Height - mandatory if 'NMEA' is set to 'Manual'</h4></p>
@@ -2662 +2662 @@
 <p><h4>2.11.1 <a name="obsrate">Observation Rate - optional</h4></p>
 <p>
-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 priori estimate of the expected observation rate of the incoming streams.</p><p>An empty option field (default) means that you don't want explicit information from BNC about stream outages and incoming streams that cannot be decoded.
+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 priori estimate of the expected observation rate of the incoming streams.</p><p>An empty option field (default) means that you do not want explicit information from BNC about stream outages and incoming streams that cannot be decoded.
 </p>
 
@@ -2711 +2711 @@
 </p>
 <p>
-Note the sleep command in this script which causes the system to wait for a random period of up to 60 seconds before sending the email. This should avoid overloading your mail server in case of a simultaneous failure of many streams.
+Note the sleep command in this script, which causes the system to wait for a random period of up to 60 seconds before sending the email. This should avoid overloading your mail server in case of a simultaneous failure of many streams.
 </p>
 
 <p><h4>2.12 <a name="misc">Miscellaneous</h4></p>
 <p>
-This section describes several miscellaneous options which can be applied to a single stream (mountpoint) or to all configured streams.
+This section describes several miscellaneous options, which can be applied to a single stream (mountpoint) or to all configured streams.
 </p>
 
@@ -2728 +2728 @@
 <p><h4>2.12.1 <a name="miscmount">Mountpoint - optional </h4></p>
 <p>
-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.
+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 do not want BNC to apply any of these options.
 </p>
 
@@ -2784 +2784 @@
 
 <p>
-Please note further that RTCM Version 3 message types 1084 for GLONASS don't contain GLONASS channel numbers. Observations from these messages can only be decoded when you include 1020 GLONASS ephemeris messages to your stream which contain the channels. You could also consider adding a second stream carrying 1087 GLONASS observation messages or 1020 GLONASS ephemeris messages as both contain the GLONASS channel numbers.
+Please note further that RTCM Version 3 message types 1084 for GLONASS do not contain GLONASS channel numbers. Observations from these messages can only be decoded when you include 1020 GLONASS ephemeris messages to your stream, which contain the channels. You could also consider adding a second stream carrying 1087 GLONASS observation messages or 1020 GLONASS ephemeris messages as both contain the GLONASS channel numbers.
 </p>
 <p>
@@ -2790 +2790 @@
 <p>Logged time stamps refer to message reception time and allow understanding repetition rates. Enter 'ALL' if you want to log this information from all configured streams. Beware that the size of the logfile can rapidly increase depending on the number of incoming RTCM streams.
 </p>
-<p>This option is primarily meant for test and evaluation. Use it to figure out what exactly is produced by a specific GNSS receiver's configuration. An empty option field (default) means that you don't want BNC to print message type numbers and antenna information carried in RTCM streams.
+<p>This option is primarily meant for test and evaluation. Use it to figure out what exactly is produced by a specific GNSS receiver's configuration. An empty option field (default) means that you do not want BNC to print message type numbers and antenna information carried in RTCM streams.
 </p>
 
@@ -2802 +2802 @@
 </p>
 <p>
- An empty option field (default) means that you don't want BNC to apply the TCP/IP port output option.
+ An empty option field (default) means that you do not want BNC to apply the TCP/IP port output option.
 </p>
 
@@ -2861 +2861 @@
 </p>
 <p>
-If you don't pull Broadcast Corrections, BNC will switch with its solution to 'Single Point Positioning' (SPP) mode.
+If you do not pull Broadcast Corrections, BNC will switch with its solution to 'Single Point Positioning' (SPP) mode.
 </p>
 
@@ -2896 +2896 @@
 </p>
 <p>
-If you don't specify a 'Corrections stream' BNC will fall back from a PPP solution to a Single Point Positioning (SPP) solution.
+If you do not specify a 'Corrections stream' BNC will fall back from a PPP solution to a Single Point Positioning (SPP) solution.
 </p>
 
@@ -2904 +2904 @@
 </p>
 <p>
-If you don't specify a 'Correction file', BNC will fall back from a PPP solution to a Single Point Positioning (SPP) solution.
+If you do not specify a 'Correction file', BNC will fall back from a PPP solution to a Single Point Positioning (SPP) solution.
 </p>
 
@@ -2912 +2912 @@
 </p>
 <p>
-Default value for 'ANTEX file' is an empty option field, meaning that you don't want to correct observations for Antenna Phase Center offsets and variations.
+Default value for 'ANTEX file' is an empty option field, meaning that you do not want to correct observations for Antenna Phase Center offsets and variations.
 </p>
 
@@ -2930 +2930 @@
 <li>Only for static observations from a stationary receiver:<br>Approximate a priori XYZ coordinate [m] of the station's marker; specify '0.0 0.0 0.0' if unknown or when observations come from a mobile receiver.</li><br>
 <li>Nort, East and Up component [m] of antenna eccentricity which is the difference between Antenna Reference Point (ARP) and a nearby marker position; when specifying the antenna eccentricity BNC will produce coordinates referring to the marker position and not referring to ARP; specify '0.0 0.0 0.0' if eccentricity is unknown or the ARP itself is understood as the marker.</li><br>
-<li>Receiver's antenna name as defined in your ANTEX file (see below); Observations will be corrected for the Antenna Phase Center (APC) offsets and variations which may result in a reduction of a few centimeters at max; the specified name must consist of 20 characters; add trailing blanks if the antenna name has less than 20 characters; examples:<br><pre>
+<li>Receiver's antenna name as defined in your ANTEX file (see below); Observations will be corrected for the Antenna Phase Center (APC) offsets and variations, which may result in a reduction of a few centimeters at max; the specified name must consist of 20 characters; add trailing blanks if the antenna name has less than 20 characters; examples:<br><pre>
 &nbsp; &nbsp;'JPSREGANT_SD_E      ' (no radome)
 &nbsp; &nbsp;'LEIAT504        NONE' (no radome)
 &nbsp; &nbsp;'LEIAR25.R3      LEIT' (radome)</pre>
-Leave antenna name blank if you don't want to correct observations for APC offsets and variations or if you don't know the antenna name.</li><br>
+Leave antenna name blank if you do not want to correct observations for APC offsets and variations or if you do not know the antenna name.</li><br>
 <li>
 Receiver type following the naming convention for IGS equipment as defined in <u>https://igscb.jpl.nasa.gov/igscb/station/general/rcvr_ant.tab</u>. Specifying the receiver type is only required when saving SINEX Troposphere files. In those files it becomes part of the 'SITE/RECEIVER' specifications, see section 'SNX TRO Directory'.
@@ -3002 +3002 @@
 </p>
 <ul>
-<li> Record 'WTZR0' describes a stream from a stationary receiver with known a priori marker coordinate, antenna eccentricity, antenna and radome type and receiver tpye.</li>
+<li> Record 'WTZR0' describes a stream from a stationary receiver with known a priori marker coordinate, antenna eccentricity, antenna and radome type and receiver type.</li>
 <li> Record 'CUT07' describes a stream from a stationary receiver with known a priori marker coordinate, antenna eccentricity and antenna and radome type. The receiver type is unknown.</li>
 <li> Record 'FFMJ1' describes a stream from a stationary receiver with known a priori marker coordinate and antenna eccentricity but unknown antenna, radome and receiver type.</li>
@@ -3153 +3153 @@
 </pre>
 <p>
- Depending on selected processing options you find 'GPS Time' stampes (yyyy-mm-dd_hh:mm:ss.sss) followed by
+ Depending on selected processing options you find 'GPS Time' stamps (yyyy-mm-dd_hh:mm:ss.sss) followed by
 <ul>
 <li>RES: Code and phase residuals for contributing GNSS systems in [m]<br>Given per satellite with cIF/lIF for ionosphere-free linear combination of code/phase observations,</li>
@@ -3167 +3167 @@
 </p>
 <p>
-Default value for 'Logfile directory' is an empty option field, meaning that you don't want to save daily PPP logfiles on disk. If a specified directory does not exist, BNC will not create PPP logfiles.
+Default value for 'Logfile directory' is an empty option field, meaning that you do not want to save daily PPP logfiles on disk. If a specified directory does not exist, BNC will not create PPP logfiles.
 </p>
 
@@ -3305 +3305 @@
 </p>
 <p>
-Default 'Sampling' rate is '0', meaning that all troposphere estimates will be save on disk.
+Default 'Sampling' rate is '0', meaning that all troposphere estimates will be saved on disk.
 </p>
 
@@ -3330 +3330 @@
 <p><h4>2.13.2.2 <a name="pppnehsigma">Sigma North/East/Up - mandatory</h4></p>
 <p>
-Enter a sigmas in meters for the initial coordinate components. A value of 100.0 (default) may be an appropriate choice. However, this value may be significantly smaller (e.g. 0.01) when starting for example from a station with a well-known position in so-called Quick-Start mode.
+Enter sigmas in meters for the initial coordinate components. A value of 100.0 (default) may be an appropriate choice. However, this value may be significantly smaller (e.g. 0.01) when starting for example from a station with a well-known position in so-called Quick-Start mode.
 </p>
 
@@ -3381 +3381 @@
 </ul>
 </p>
-<p>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.
-</p>
-<p>Specifying 'no' means that you don't at all want BNC to use observations from the affected GNSS system.
+<p>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.
+</p>
+<p>Specifying 'no' means that you do not at all want BNC to use observations from the affected GNSS system.
 </p>
 
@@ -3404 +3404 @@
 
 <p>
-As the convergence characteristic of a PPP solution can be influenced by the ratio of sigmas for code and phase, you may like to introduce sigmas which differ from the default values.
-<ul>
-<li>Introducing a smaller sigma (higher accuracy) for code observations or a bigger sigma for phase observations leads to better results shortly after program start. However, it may take more time till you finally get the best possible solution.</li>
+As the convergence characteristic of a PPP solution can be influenced by the ratio of sigmas for code and phase, you may like to introduce sigmas, which differ from the default values.
+<ul>
+<li>Introducing a smaller sigma (higher accuracy) for code observations or a bigger sigma for phase observations leads to better results shortly after program start. However, it may take more time untill you finally get the best possible solution.</li>
 <li>Introducing a bigger sigma (lower accuracy) for code observations or a smaller sigma for phase observations may lead to less accurate results shortly after program start and thus a prolonged period of convergence but could provide better positions in the long run.</li>
 </ul>
@@ -3444 +3444 @@
 <p><h4>2.13.3.7 <a name="pppwaitclockcorr">Wait for Clock Corrections - optional</h4></p>
 <p>
-Specifying 'no' for option 'Wait for clock corr.' means that BNC processes each epoch of data immediately after its arrival using satellite clock corrections available at that time. A non-zero value means that epochs of data are buffered and the processing of each epoch is postponed till satellite clock corrections not older than 'Wait for clock corr.' seconds are available. Specifying a value of half the update rate of the clock corrections (e.g. 5 sec) may be appropriate. Note that this causes an additional delay of the PPP solutions in the amount of half of the update rate.
+Specifying 'no' for option 'Wait for clock corr.' means that BNC processes each epoch of data immediately after its arrival using satellite clock corrections available at that time. A non-zero value means that epochs of data are buffered and the processing of each epoch is postponed untill satellite clock corrections not older than 'Wait for clock corr.' seconds are available. Specifying a value of half the update rate of the clock corrections (e.g. 5 sec) may be appropriate. Note that this causes an additional delay of the PPP solutions in the amount of half of the update rate.
 </p>
 <p>
@@ -3455 +3455 @@
 <p><h4>2.13.3.8 <a name="pppseeding">Seeding - optional if a priori coordinates specified in 'Coordinates file'</h4></p>
 <p>
-Enter the length of a startup period in seconds for which you want to fix the PPP solution to an known position, see option 'Coordinates file'. Constraining a priori coordinates is done in BNC through setting their white 'Noise' temporarily to zero.
-</p>
-<p>
-This so-called Quick-Start option allows the PPP solutions to rapidly converge after startup. It requires that the antenna remains unmoved on the known position throughout the defined period. A value of '60' seconds is likely to be an appropriate choice for 'Seeding'. Default is an empty option field, meaning that you don't want BNC to start in Quick-Start mode.
-<p>
-You may need to create your own reference coordinate beforehand through running BNC for an hour in normal mode before applying the 'Seeding' option. Don't forget to introduce realistic North/East/Up sigmas under panel 'PPP (2)' corresponding to the coordinate's precision.
-</p>
-
-<p>
-'Seeding' has also a function for bridging gaps in PPP solutions from failures caused e.g. by longer lasting outages. Should the time span between two consecutive solutions exceed the limit of 60 seconds (maximum solution gap, hard-wired), the algorithm fixes the latest derived coordinate for a period of 'Seeding' seconds. This option avoids time-consuming reconvergences and makes especially sense for stationary operated receivers where convergence can be enforced because a good approximation for the receiver position is known.  
+Enter the length of a startup period in seconds for which you want to fix the PPP solution to a known position, see option 'Coordinates file'. Constraining a priori coordinates is done in BNC through setting their white 'Noise' temporarily to zero.
+</p>
+<p>
+This so-called Quick-Start option allows the PPP solutions to rapidly converge after startup. It requires that the antenna remains unmoved on the known position throughout the defined period. A value of '60' seconds is likely to be an appropriate choice for 'Seeding'. Default is an empty option field, meaning that you do not want BNC to start in Quick-Start mode.
+<p>
+You may need to create your own reference coordinate beforehand through running BNC for an hour in normal mode before applying the 'Seeding' option. Do not forget to introduce realistic North/East/Up sigmas under panel 'PPP (2)' corresponding to the coordinate's precision.
+</p>
+
+<p>
+'Seeding' has also a function for bridging gaps in PPP solutions from failures caused e.g. by longer lasting outages. Should the time span between two consecutive solutions exceed the limit of 60 seconds (maximum solution gap, hard-wired), the algorithm fixes the latest derived coordinate for a period of 'Seeding' seconds. This option avoids time-consuming reconvergences and makes especially sense for stationarily operated receivers where convergence can be enforced because a good approximation for the receiver position is known.  
 </p>
 
@@ -3484 +3484 @@
 </p>
 <p>
-Note that a PPP dicplacements time series makes only sense for a stationary operated receiver.
+Note that a PPP dicplacements time series makes only sense for a stationarily operated receiver.
 </p>
 
 <p><h4>2.13.4.2 <a name="pppaudioresp">Audio Response - optional</h4></p>
 <p>
-For natural hazard prediction and monitoring landslides it may be appropriate to generate audio alerts. For that you can specify an 'Audio response' threshold in meters. A beep is produced by BNC whenever a horizontal PPP coordinate component differs by more than the threshold value from the specified marker coordinate.
-</p>
-<p>
-Default is an empty option field, meaning that you don't want BNC to produce acoustic warnings.
+For natural hazard prediction and monitoring landslides, it may be appropriate to generate audio alerts. For that you can specify an 'Audio response' threshold in meters. A beep is produced by BNC whenever a horizontal PPP coordinate component differs by more than the threshold value from the specified marker coordinate.
+</p>
+<p>
+Default is an empty option field, meaning that you do not want BNC to produce acoustic warnings.
 </p>
 
@@ -3524 +3524 @@
 <p><h4>2.13.4.4.1 <a name="pppdotsize">Size - mandatory before pushing 'Open Map'</h4></p>
 <p>
-Specify the size of dots showing the rover position. A dot size of '3' may be appropriate. The maximum possible dot size is '10'. An empty option field or a size of '0' would mean that you don't want BNC to show the rover's track on the map.
+Specify the size of dots showing the rover position. A dot size of '3' may be appropriate. The maximum possible dot size is '10'. An empty option field or a size of '0' would mean that you do not want BNC to show the rover's track on the map.
 </p>
 
@@ -3542 +3542 @@
 </p>
 <p>
-In the Kalman Filter approach, satellite clocks estimated by individual Analyses Centers (ACs) are used as pseudo observations within the adjustment process. Each observation is modeled as a linear function (actually a simple sum) of three estimated parameters: AC specific offset, satellite specific offset common to all ACs, and the actual satellite clock correction which represents the result of the combination. These three parameter types differ in their statistical properties. The satellite clock offsets are assumed to be static parameters while AC specific and satellite specific offsets are stochastic parameters with appropriate white noise.
+In the Kalman Filter approach, satellite clocks estimated by individual Analyses Centers (ACs) are used as pseudo observations within the adjustment process. Each observation is modeled as a linear function (actually a simple sum) of three estimated parameters: AC specific offset, satellite specific offset common to all ACs, and the actual satellite clock correction, which represents the result of the combination. These three parameter types differ in their statistical properties. The satellite clock offsets are assumed to be static parameters while AC specific and satellite specific offsets are stochastic parameters with appropriate white noise.
  The solution is regularized by a set of minimal constraints. After a change of one of the three values 'SSR Provider ID', 'SSR Solution ID', or 'IOD SSR', the satellite clock offsets belonging to the corresponding analysis center are reset in the adjustment.
 </p>
@@ -3562 +3562 @@
 </p>
 <p>
-Note that the combination process requires real-time access to Broadcast Ephemeris. So, in addition to the orbit and clock correction streams BNC must pull a stream carrying Broadcast Ephemeris in the form of RTCM Version 3 messages. Stream 'RTCM3EPH' on caster <u>products.igs-ip.net</u> is an example for that. Note further that BNC will ignore incorrect or outdated Broadcast Ephemeris data when necessary, leaving a note 'WRONG EPHEMERIS' or 'OUTDATED EPHEMERIS' in the logfile.
+Note that the combination process requires real-time access to Broadcast Ephemeris. Therefore, in addition to the orbit and clock correction streams BNC must pull a stream carrying Broadcast Ephemeris in the form of RTCM Version 3 messages. Stream 'RTCM3EPH' on caster <u>products.igs-ip.net</u> is an example for that. Note further that BNC will ignore incorrect or outdated Broadcast Ephemeris data when necessary, leaving a note 'WRONG EPHEMERIS' or 'OUTDATED EPHEMERIS' in the logfile.
 </p>
 
@@ -3570 +3570 @@
 
 <p>
-With respect to IGS, it is important to understand that a major effect in the combination of GNSS orbit and clock correction streams is the selection of ACs to include. It is likely that a combination product could be improved in accuracy by using only the best two or three ACs. However, with only a few ACs to depend on, the reliability of the combination product could suffer and the risk of total failures increases. So there is an important tradeoff here that must be considered when selecting streams for a combination. The major strength of a combination product is its reliability and stable median performance which can be much better than that of any single AC product.
+With respect to IGS, it is important to understand that a major effect in the combination of GNSS orbit and clock correction streams is the selection of ACs to include. It is likely that a combination product could be improved in accuracy by using only the best two or three ACs. However, with only a few ACs to depend on, the reliability of the combination product could suffer and the risk of total failures increases. So there is an important tradeoff here that must be considered when selecting streams for a combination. The major strength of a combination product is its reliability and stable median performance, which can be much better than that of any single AC product.
 </p>
 <p>
@@ -3578 +3578 @@
 The following recursive algorithm is used to detect orbit outliers in the Kalman Filter combination when Broadcast Corrections are provided by several ACs:
 <br>
-Step 1: We don't produce a combination for a certain satellite if only one AC provides corrections for it.
+Step 1: We do not produce a combination for a certain satellite if only one AC provides corrections for it.
 <br>
 Step 2: A mean satellite position is calculated as the average of positions from all ACs.
 <br>
-Step 3: For each AC and satellite the 3D distance between individual and mean satellite position is calculated.
+Step 3: For each AC and satellite, the 3D distance between individual and mean satellite position is calculated.
 <br>
 Step 4: We find the greatest difference between AC specific and mean satellite positions.
 <br>
-Step 5: If that is less than a threshold, the conclusion is that we don't have an outlier and can proceed to the next epoch.
+Step 5: If that is less than a threshold, the conclusion is that we do not have an outlier and can proceed to the next epoch.
 <br>
 Step 6: If that is greater than a threshold, then corrections of the affiliated AC are ignored for the affected epoch and the outlier detection restarts with step 1.
@@ -3599 +3599 @@
 </p>
 <p>
-The sequence of entries in the 'Combine Corrections' table is not of importance. Note that the orbit information in the final combination stream is just copied from one of the incoming streams. The stream used for providing the orbits may vary over time: if the orbit providing stream has an outage then BNC switches to the next remaining stream for getting hold of the orbit information.</p>
+The sequence of entries in the 'Combine Corrections' table is not of importance. Note that the orbit information in the final combination stream is just copied from one of the incoming streams. The stream used for providing the orbits may vary over time: if the orbit-providing stream has an outage then BNC switches to the next remaining stream for getting hold of the orbit information.</p>
 <p>
 It is possible to specify only one Broadcast Ephemeris correction stream in the 'Combine Corrections' table. Instead of combining corrections from several sources, BNC will then merge the single corrections stream with Broadcast Ephemeris to save results in SP3 and/or Clock RINEX format when specified accordingly under the 'Upload Corrections' panel. Note that in such a BNC application you must not pull more than one Broadcast Ephemeris correction stream even if a second stream would provide the same corrections from a backup caster.
 </p>
 <p>
-Default is an empty 'Combine Corrections' table meaning that you don't want BNC to combine orbit and clock correction streams.
+Default is an empty 'Combine Corrections' table meaning that you do not want BNC to combine orbit and clock correction streams.
 </p>
 
@@ -3613 +3613 @@
 
 <p>
-The following screenshots describe an example setup of BNC when combining Broadcast Correction streams and uploading them to an Ntrip Broadcaster. Note that this application requires specifying options under panels 'Combine Corrections' and 'Upload Corrections'. The example uses the combination product to simultaneously carry out an 'INTERNAL' PPP solution which allows monitoring the quality of the combination product in the space domain.
+The following screenshots describe an example setup of BNC when combining Broadcast Correction streams and uploading them to an Ntrip Broadcaster. Note that this application requires specifying options under panels 'Combine Corrections' and 'Upload Corrections'. The example uses the combination product to simultaneously carry out an 'INTERNAL' PPP solution, which allows monitoring the quality of the combination product in the space domain.
 </p>
 
@@ -3766 +3766 @@
 </p>
 <p>
-Having an empty 'Upload Table' is default and means that you don't want BNC to upload orbit and clock correction streams to any Ntrip Broadcaster.
+Having an empty 'Upload Table' is default and means that you do not want BNC to upload orbit and clock correction streams to any Ntrip Broadcaster.
 </p>
 
@@ -3972 +3972 @@
 Note that '${GPSWD}' produces the GPS Week and Day number in the filename.</p>
 <p>
-Default is an empty option field, meaning that you don't want BNC to save the uploaded stream content in daily SP3 files.
-</p>
-<p>
-As a SP3 file content should be referred to the satellites' Center of Mass (CoM) while Broadcast Corrections are referred to the satellites' APC, an offset has to be applied which is available from an IGS ANTEX file (see option 'ANTEX File' below). Hence you should specify the 'ANTEX File' path there if you want to save the stream content in SP3 format. If you don't specify an 'ANTEX File' path, the SP3 file content will be referred to the satellites APCs.
+Default is an empty option field, meaning that you do not want BNC to save the uploaded stream content in daily SP3 files.
+</p>
+<p>
+As a SP3 file content should be referred to the satellites' Center of Mass (CoM) while Broadcast Corrections are referred to the satellites' APC, an offset has to be applied which is available from an IGS ANTEX file (see option 'ANTEX File' below). Hence, you should specify the 'ANTEX File' path there if you want to save the stream content in SP3 format. If you do not specify an 'ANTEX File' path, the SP3 file content will be referred to the satellites APCs.
 </p>
 <p>
@@ -4059 +4059 @@
 <p><h4>2.15.10 <a name="upantex">ANTEX File - mandatory if 'SP3 File' is specified</h4></p>
 <p>
-IGS provides a file containing absolute phase center variations for GNSS satellite and receiver antennas in ANTEX format. Entering the full path to such an ANTEX file is required here for referring the SP3 file content to the satellite's Center of Mass (CoM). If you don't specify a ANTEX file, the SP3 file will contain orbit information which is referred to Antenna Phase Center (APC) instead of CoM.
+IGS provides a file containing absolute phase center variations for GNSS satellite and receiver antennas in ANTEX format. Entering the full path to such an ANTEX file is required here for referring the SP3 file content to the satellite's Center of Mass (CoM). If you do not specify an ANTEX file, the SP3 file will contain orbit information which is referred to Antenna Phase Center (APC) instead of CoM.
 </p>
 
@@ -4085 +4085 @@
 <p><h4>2.16.1 <a name="brdcserver">Host &amp; Port - optional</h4></p>
 <p>
-Specify the 'Host' IP number or URL of an Ntrip Broadcaster to upload the stream. An empty option field means that you don't want to upload Broadcast Ephemeris.
+Specify the 'Host' IP number or URL of an Ntrip Broadcaster to upload the stream. An empty option field means that you do not want to upload Broadcast Ephemeris.
 </p>
 <p>
@@ -4131 +4131 @@
 </li>
 <li>
-In case you need to log the raw data as is, BNC allows users to by-pass its decoders and directly save the input in daily logfiles. To do this, specify the decoder string as 'ZERO'. The generated filenames are created from the characters of the streams mountpoints plus two-digit numbers each for year, month, and day. Example: Setting the 'decoder' string for mountpoint WTZZ0 to 'ZERO' and running BNC on March 29, 2007 would save the raw data in a file named WTZZ0_070329.
+In case you need to log the raw data as it is, BNC allows users to by-pass its decoders and directly save the input in daily logfiles. To do this, specify the decoder string as 'ZERO'. The generated filenames are created from the characters of the streams mountpoints plus two-digit numbers each for year, month, and day. Example: Setting the 'decoder' string for mountpoint WTZZ0 to 'ZERO' and running BNC on March 29, 2007 would save the raw data in a file named WTZZ0_070329.
 </li>
 <li>
 BNC can also retrieve streams from virtual reference stations (VRS). To initiate these streams, an approximate rover position needs to be sent in NMEA format to the Ntrip Broadcaster. In return, a user-specific data stream is generated, typically by Network RTK software. VRS streams are indicated by a 'yes' in the source-table as well as in the 'nmea' column on the 'Streams' canvas in BNC's main window. They are customized exactly to the latitude and longitude transmitted to the Ntrip Broadcaster via NMEA GGA sentences.
-<br>If NMEA GGA sentences are not coming from a serial connected GNSS rover, BNC simulates them from the default latitude and longitude of the source-table as shown in the 'lat' and 'long' columns on the 'Streams' canvas. However, in many cases you would probably want to change these defaults according to your requirement. Double-click on 'lat' and 'long' fields, enter the values you wish to send and then hit Enter. The format is in positive north latitude degrees (e.g. for northern hemisphere: 52.436, for southern hemisphere: -24.567) and eastern longitude degrees (example: 358.872 or -1.128). Only streams with a 'yes' in their 'nmea' column can be edited. The position must preferably be a point within the VRS service area of the network. RINEX files generated from these streams will contain an additional COMMENT line in the header beginning with 'NMEA' showing the 'lat' and 'long' used.
+<br>If NMEA GGA sentences are not coming from a serially connected GNSS rover, BNC simulates them from the default latitude and longitude of the source-table as shown in the 'lat' and 'long' columns on the 'Streams' canvas. However, in many cases you would probably want to change these defaults according to your requirement. Double-click on 'lat' and 'long' fields, enter the values you wish to send and then hit Enter. The format is in positive north latitude degrees (e.g. for northern hemisphere: 52.436, for southern hemisphere: -24.567) and eastern longitude degrees (example: 358.872 or -1.128). Only streams with a 'yes' in their 'nmea' column can be edited. The position must preferably be a point within the VRS service area of the network. RINEX files generated from these streams will contain an additional COMMENT line in the header beginning with 'NMEA' showing the 'lat' and 'long' used.
 <br>Note that when running BNC in a Local Area Network (LAN), NMEA strings may be blocked by a proxy server, firewall or virus scanner when not using the Ntrip Version 2 transport protocol.
 </li>
@@ -4156 +4156 @@
 <p><h4>2.18 <a name="logs">Logging Canvas</h4></p>
 <p>
-The 'Logging Canvas' above the bottom menu bar on the main window labeled 'Log', 'Throughput', 'Lacenty', and 'PPP Plot' provides control of BNC's activities. Tabs are available for continuously showing logfile content, for a plot controlling the bandwidth consumption, a plot showing stream latencies, and for time series plots of PPP results.
+The 'Logging Canvas' above the bottom menu bar on the main window labeled 'Log', 'Throughput', 'Latency', and 'PPP Plot' provides control of BNC's activities. Tabs are available for continuously showing logfile content, for a plot controlling the bandwidth consumption, a plot showing stream latencies, and for time series plots of PPP results.
 </p>
 <p><h4>2.18.1 <a name="logfile">Log</h4></p>
@@ -4181 +4181 @@
 <p><h4>2.18.4 <a name="ppptab">PPP Plot</h4></p>
 <p>
-Precise Point Positioning time series of North (red), East (green) and Up (blue) coordinate components are shown in the 'PPP Plot' tab when a 'Mountpoint' option is defined under PPP (4). Values are either referred to reference coordinates (if specified) or referred to the first estimated set of coordinate components. The time as given in format [hh:mm] refers to GPS Time. The sliding PPP time series window covers a period of 5 minutes. Note that it may take up to 30 seconds or more till the first PPP solutions becomes available. The following figure shows the screenshot of a PPP time series plot of North, East and Up coordinate displacements.
+Precise Point Positioning time series of North (red), East (green) and Up (blue) coordinate components are shown in the 'PPP Plot' tab when a 'Mountpoint' option is defined under PPP (4). Values are either referred to reference coordinates (if specified) or referred to the first estimated set of coordinate components. The time as given in format [hh:mm] refers to GPS Time. The sliding PPP time series window covers a period of 5 minutes. Note that it may take up to 30 seconds or more untill the first PPP solutions becomes available. The following figure shows the screenshot of a PPP time series plot of North, East and Up coordinate displacements.
 </p>
 
@@ -4197 +4197 @@
 <p><h4>2.19.1 <a name="streamadd">Add Stream</h4></p>
 <p>
-Button 'Add Stream' allows you to pull streams either from a Ntrip Broadcaster or from a TCP/IP port, UPD port, or serial port.
+Button 'Add Stream' allows you to pull streams either from an Ntrip Broadcaster or from a TCP/IP port, UPD port, or serial port.
 </p>
 
@@ -4233 +4233 @@
 </p>
 <p>
-Hit 'OK' to return to the main window. If you wish you can click on 'Add Stream' and repeat the process to retrieve streams from different casters.
+Hit 'OK' to return to the main window. If you wish, you can click on 'Add Stream' and repeat the process to retrieve streams from different casters.
 </p>
 <p><img src="IMG/screenshot05.png"/></p>
@@ -4260 +4260 @@
 <ul>
 <li>Try using option '2' if your streams are otherwise blocked by a proxy server operated in front of BNC.</li>
-<li>When using Ntrip Version 2 via SSL (option '2s') you need to specify the appropriate 'Caster port' for that. It's usually port number 443. Clarify 'SSL' options offered in panel 'Network'.</li>
+<li>When using Ntrip Version 2 via SSL (option '2s') you need to specify the appropriate 'Caster port' for that. It is usually port number 443. Clarify 'SSL' options offered in panel 'Network'.</li>
 <li>Option 'R' or 'U' may be selected if latency is more important than completeness for your application. Note that the latency reduction is likely to be in the order of 0.5 sec or less. Note further that options 'R' (RTSP/RTP mode) and 'U' (UDP mode) are not accepted by proxy servers and a mobile Internet Service Provider may not support it.</li>
 </ul>
@@ -4332 +4332 @@
 <li>Select the 'Parity' for the serial input. Note that parity is often set to 'NONE'.</li>
 <li>Select the number of 'Stop bits' for the serial input. Note that often '1' stop bit is used.</li>
-<li>Select a 'Flow control' for the serial link. Select 'OFF' if you don't know better.</li>
-</ul>
-</p>
-<p>
-When selecting one of the serial communication options listed above, make sure that you pick those configured to the serial connected GNSS receiver.
-</p>
-
-<p>
-Streams received from a serial connected GNSS receiver show up with an 'S' (for <u>S</u>erial Port, no Ntrip) in the 'Streams' canvas section on BNC's main window. Latitude and longitude are to be entered just for informal reasons.
+<li>Select a 'Flow control' for the serial link. Select 'OFF' if you do not know better.</li>
+</ul>
+</p>
+<p>
+When selecting one of the serial communication options listed above, make sure that you pick those configured to the serially connected GNSS receiver.
+</p>
+
+<p>
+Streams received from a serially connected GNSS receiver show up with an 'S' (for <u>S</u>erial Port, no Ntrip) in the 'Streams' canvas section on BNC's main window. Latitude and longitude are to be entered just for informal reasons.
 <p>
 
@@ -4417 +4417 @@
 <p>
 It is obvious that BNC requires graphics support when started in interactive
-mode. But, note that graphics support is also required when producing plots in
+mode. However, note that graphics support is also required when producing plots in
 batch mode (option -nw). Windows and Mac OS X systems always support graphics. For
 producing plots in batch mode on Linux systems you must make sure that at
@@ -4644 +4644 @@
 [Mod] PPP default options<br>
 [Add] Example configuration for SP3 file comparison<br>
-[Add] Chose between code and phase observations when in PPP SSR I mode<br>
+[Add] Choose between code and phase observations when in PPP SSR I mode<br>
 [Bug] Reset time series plot when restarting PPP in post processing mode<br>
 [Add] Broadcast ephemeris check regarding allowed age of data sets<br>
@@ -4714 +4714 @@
 <li>Application not limited to one particular plain or coded stream content; ability to distribute any kind of GNSS data;</li>
 <li>Potential to support mass usage; disseminating hundreds of streams simultaneously for thousands of users possible when applying modified Internet Radio broadcasting software;</li>
-<li>Considering security needs; stream providers and users don't necessarily get into contact, streams often not blocked by firewalls or proxy servers protecting Local Area Networks;</li>
+<li>Considering security needs; stream providers and users do not necessarily get into contact, streams often not blocked by firewalls or proxy servers protecting Local Area Networks;</li>
 <li>Enables streaming over mobile IP networks because of using TCP/IP.</li>
 </ul>
@@ -4741 +4741 @@
 <ul>
 <li>Cleared and fixed design problems and HTTP protocol violations;</li>
-<li>Replaced non standard directives;</li>
+<li>Replaced nonstandard directives;</li>
 <li>Chunked transfer encoding;</li>
 <li>Improvements in header records;</li>
@@ -4748 +4748 @@
 </ul>
 
-<p>Ntrip Version 2 allows to either communicate in TCP/IP mode or in RTSP/RTP mode or in UDP mode whereas Version 1 is limited to TCP/IP only. It furthermore allows using the Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL) cryptographic protocols for secure Ntrip communication over the Internet.
+<p>Ntrip Version 2 allows to communicate either in TCP/IP mode or in RTSP/RTP mode or in UDP mode whereas Version 1 is limited to TCP/IP only. It furthermore allows using the Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL) cryptographic protocols for secure Ntrip communication over the Internet.
 </p>