Changeset 4059 in ntrip for trunk

Timestamp:

Apr 26, 2012, 3:32:05 PM (13 years ago)

Author:

weber

Message:

Typos corrected

File:

• trunk/BNC/bnchelp.html (modified) (47 diffs)

trunk/BNC/bnchelp.html

@@ -51 +51 @@
 <li>convert the IGS Earth-Centered-Earth-Fixed clocks and and orbits into corrections to Broadcast Ephemeris with radial, along-track and cross-track components,</li>
 <li>upload the clock and orbit corrections as an RTCM Version 3 stream to an NTRIP Broadcaster,</li>
-<li>refer the clock and orbit corretions to a specific reference system,</li>
+<li>refer the clock and orbit corrections to a specific reference system,</li>
 <li>log the Broadcast Ephemeris clock corrections as Clock RINEX files for further processing using other tools than BNC,</li>
 <li>log the Broadcast Ephemeris orbit corrections as SP3 files for further processing using other tools than BNC,</li>
@@ -70 +70 @@
 <li>RTNET, a plain ASCII format defined within BNC to receive orbits and clock from a serving GNSS engine.
 </ul>
-Furtermore, BNC allows to by-pass its decoding and conversion algorithms, leave whatever is received untouched and save it in files.
-</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 pupose 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 Broadcast Corrections. 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.
+Furthermore, BNC allows to by-pass its decoding and conversion algorithms, leave whatever is received untouched and save it in files.
+</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 Broadcast Corrections. 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>
@@ -127 +127 @@
 
 <p>
-The usual handling of BNC is that you first select a number of streams ('Add Stream'). Any stream configured to BNC shows up on the 'Streams' canvas in the middle of BNC's main window. You then go through BNC's various configuration tabs to select a combination of input, processing and output options before you start the program ('Start'). Most configuration tabs are dedicated to a certain functionality of BNC. If the first option field on such a configuration tab is empty, the affected functionality is - appart from a few exceptions -  deactivated.</p>
+The usual handling of BNC is that you first select a number of streams ('Add Stream'). Any stream configured to BNC shows up on the 'Streams' canvas in the middle of BNC's main window. You then go through BNC's various configuration tabs to select a combination of input, processing and output options before you start the program ('Start'). Most configuration tabs are dedicated to a certain functionality of BNC. If the first option field on such a configuration tab is empty, the affected functionality is - apart from a few exceptions -  deactivated.</p>
 
 Records of BNC's activities are shown in the 'Log' tab. The bandwidth consumption per stream, the latency of incoming observations and a PPP time series for coordinates are shown in the 'Throughput', 'Latency' and 'PPP Plot' tabs of the main window.
@@ -287 +287 @@
 <p><a name="topmenu"><h4>3.1. Top Menu Bar</h4></p>
 <p>
-The top menu bar allows to select a font for the BNC windows, save configured options or quit the program execution. It also provides access to a program documentation.
+The top menu bar allows to select a font for the BNC windows, save configured options, or quit the program execution. It also provides access to a program documentation.
 </p>
 
@@ -340 +340 @@
 
 <p><a name="ssl"><h4>3.2.2 SSL - Transport Layer Security</h4></p>
-<p>Communication with an NTRIP Broadcaster over SSL requires the exchange of client and/or server certificates. Specify the path to a directory where you save certificates on your system. You may like to check out <u>http://software.rtcm-ntrip.org/wiki/Certificates</u> for a list of known NTRIP Server certificates. Don't try communication via SSL if you are not sure wheter this is supported by the involved NTRIP Broadcaster. </p>
+<p>Communication with an NTRIP Broadcaster over SSL requires the exchange of client and/or server certificates. Specify the path to a directory where you save certificates on your system. You may like to check out <u>http://software.rtcm-ntrip.org/wiki/Certificates</u> for a list of known NTRIP Server certificates. Don't try communication via SSL if you are not sure whether this is supported by the involved NTRIP Broadcaster. </p>
 <p>SSL communication may involve queries coming from the NTRIP Broadcaster. Tick 'Ignore SSL authorization erros' if you don't want to be bothered with this. Note that SSL communication is usually done over port 443.</p>
 
@@ -376 +376 @@
 </p>
 <p>
-Data will be saved in blocks in the received format seperated by ASCII time stamps like (example):
+Data will be saved in blocks in the received format separated by ASCII time stamps like (example):
 <pre>
 2010-08-03T18:05:28 RTCM3EPH RTCM_3 67
@@ -496 +496 @@
 <p><a name="rnxscript"><h4>3.4.6 Script - optional</h4></p>
 <p>
-Whenever a RINEX Observation file is saved, you might want to compress, copy or upload it immediately via FTP. BNC allows you to execute a script/batch file to carry out these operations. To do that specify the full path of the script/batch file here. BNC will pass the RINEX Observation file path to the script as a command line parameter (%1 on Windows systems, $1 on Unix/Linux/Mac systems).
+Whenever a RINEX Observation file is saved, you might want to compress copy or upload it immediately via FTP. BNC allows you to execute a script/batch file to carry out these operations. To do that specify the full path of the script/batch file here. BNC will pass the RINEX Observation file path to the script as a command line parameter (%1 on Windows systems, $1 on Unix/Linux/Mac systems).
 </p> 
 <p> 
@@ -613 +613 @@
 </p>
 <p>
-RTCM has developed Version 3 messages to transport satellite clock and orbit corrections in real-time. The current set of messages concernes:
+RTCM has developed Version 3 messages to transport satellite clock and orbit corrections in real-time. The current set of messages concerns:
 <ul>
 <li>Orbit corrections to Broadcast Ephemeris</li>
@@ -845 +845 @@
 </p>
 <p>
-Specifying a value of '0' means that BNC immediately outputs all incoming Broadcast Epemeris Corrections and does not drop any of them for latency reasons.
+Specifying a value of '0' means that BNC immediately outputs all incoming Broadcast Ephemeris Corrections and does not drop any of them for latency reasons.
 </p>
 
@@ -916 +916 @@
 </p>
 <p>
-Note that 'Wait for full epoch' does not effect the RINEX Observation file content. Observations received later than 'Wait for full epoch' seconds will still be included in the RINEX Observation files.
+Note that 'Wait for full epoch' does not affect the RINEX Observation file content. Observations received later than 'Wait for full epoch' seconds will still be included in the RINEX Observation files.
 </p> 
 
@@ -1031 +1031 @@
 </p>
 
-<p><a name="obsrate"><h4>3.10.1 Observation Rate - mandatory if 'Failure threshold', 'Recovery threshold', and 'Script' is set</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 priory estimate of the expected observation rate of the incoming streams.</p><p>An empty option field (default) means that you don't want an explicit information from BNC about stream outages and incoming streams that cannot be decoded.
+<p><a name="obsrate"><h4>3.10.1 Observation Rate - mandatory if 'Failure threshold', 'Recovery threshold' and 'Script' is set</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 priory 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.
 </p> 
 
 <p><a name="advfail"><h4>3.10.2 Failure Threshold - optional</h4></p>
 <p>
-Event 'Begin_Failure' will be reported if no data is received continuously for longer than the 'Failure threshold' time. Similarly, event 'Begin_Corrupted' will be reported when corrupted data is detected by the decoder continuously for longer than this 'Failure threshold' time. The default value is set to 15 minutes and is recommended so not to innundate user with too many event reports.
+Event 'Begin_Failure' will be reported if no data is received continuously for longer than the 'Failure threshold' time. Similarly, event 'Begin_Corrupted' will be reported when corrupted data is detected by the decoder continuously for longer than this 'Failure threshold' time. The default value is set to 15 minutes and is recommended so not to inundate user with too many event reports.
 </p>
 <p>
@@ -1147 +1147 @@
 <p>
 
-<p>Logged time stamps refer to message reception time and allow to understand 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>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 testing 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 the message type numbers and antenna information carried in RTCM streams. 
@@ -1177 +1177 @@
 </p>
 <p>
-The 'PPP' string in that is followed by the selected mounpoint, a PPP time stamp in GPS Time, the number of processed satellites, and XYZ coordinates with their formal errors as derived from the implemented filter in [m]. The implemented algorithm includes an outlier and cycle slip detection. The maximum for accepted residuals is hard coded to 10 meters for code observations and 10 centimeters for phase observations.
+The 'PPP' string in that is followed by the selected mounpoint, a PPP time stamp in GPS Time, the number of processed satellites, and XYZ coordinates with their formal errors as derived from the implemented filter in [m]. The implemented algorithm includes outlier and cycle slip detection. The maximum for accepted residuals is hard coded to 10 meters for code observations and 10 centimeters for phase observations.
 </p>
 
@@ -1249 +1249 @@
 
 <p>
-Note that BNC's 'PPP Client' option can also be used offline for debugging purposes. Apply the 'File Mode' command line options for that to read a file containing synchronized observations, orbit and clock corretors, and Broadcast Ephemeris. Such a file must be generated using BNC's 'Raw output file' option. Example:
+Note that BNC's 'PPP Client' option can also be used offline for debugging purposes. Apply the 'File Mode' command line options for that to read a file containing synchronized observations, orbit and clock correctors, and Broadcast Ephemeris. Such a file must be generated using BNC's 'Raw output file' option. Example:
 </p>
 
@@ -1303 +1303 @@
 <p><a name="pppneu"><h4>3.12.3 Antenna Excentricity - optional</h4></p>
 <p>
-You may like to specify North, East and Up compoments of an antenna excentricity which is the difference between a nearby marker position and the antenna phase center. If you do so BNC will produce coordinates referring to the marker position and not referring to the antenna phase center..
+You may like to specify North, East and Up components of an antenna eccentricity which is the difference between a nearby marker position and the antenna phase center. If you do so BNC will produce coordinates referring to the marker position and not referring to the antenna phase center..
 </p>
 
@@ -1364 +1364 @@
 <p><a name="ppprecantenna"><h4>3.12.6.2 Receiver Antenna Name - optional if 'ANTEX File' is set</h4></p>
 <p>
-Specify the receiver's antenna name as defined in your ANTEX file. Observations will be corrected for the antenna phase center's offset which may result in a reduction of a few centimeters at max. Corrections for phase center variations are not yet applied by BNC. The specified name must consist of 20 characters. Add trailing blanks if the antenna name has less then 20 characters. Examples:
+Specify the receiver's antenna name as defined in your ANTEX file. Observations will be corrected for the antenna phase center's offset which may result in a reduction of a few centimeters at max. Corrections for phase center variations are not yet applied by BNC. The specified name must consist of 20 characters. Add trailing blanks if the antenna name has less than 20 characters. Examples:
 <pre>
 'JPSREGANT_SD_E      ' (no radome)
@@ -1377 +1377 @@
 <p><a name="pppsatant"><h4>3.12.6.3 Apply Satellite Antenna Offsets - optional if 'ANTEX File' is set</h4></p>
 <p>
-BNC allows to correct observations for satellite antenna phase center offsets. (This option is not yet implemented.)
+BNC allows correcting observations for satellite antenna phase center offsets. (This option is not yet implemented.)
 </p><p>
 Satellite orbit and clock corrections refer to the satellite's antenna phase centers and hence observations are <u>not</u> to be corrected for satellite antenna phase center offsets. Tick 'Apply Sat. Ant. Offsets' to force BNC to correct observations for satellite antenna phase center offsets.
@@ -1386 +1386 @@
 
 <p><a name="pppopt"><h4>3.12.7 Basic Options</h4></p>
-<p>BNC allows to use different Point Positioning processing options depending on the capability of the involved receiver and the application in mind. It also allows to introduce specific sigmas for code and phase observations as well as for reference coordinates and troposphere estimates. You may also like to carry out your PPP solution in Quick-Start mode or enforce BNC to restart a solution if the length of an outage exceeds a certain threshold.
+<p>BNC allows using different Point Positioning processing options depending on the capability of the involved receiver and the application in mind. It also allows introducing specific sigmas for code and phase observations as well as for reference coordinates and troposphere estimates. You may also like to carry out your PPP solution in Quick-Start mode or enforce BNC to restart a solution if the length of an outage exceeds a certain threshold.
 </p>
 
@@ -1471 +1471 @@
 <p><a name="pppsigc"><h4>3.11.8.1 Code - mandatory if 'Use Phase Obs' is set</h4></p>
 <p>
-When 'Use phase obs' is set in BNC, the PPP solution will be carried out using both, code and phase observations. A sigma of 5.0 m for code observations and a sigma of 0.02 m for phase observations (defauls) is used to combine both types of observations. As the convergence characteristic of a PPP solution can be influenced by the ratio of the sigmas for code and phase, you may like to introduce you own sigmas for code and phase observations which differ from the default values.
+When 'Use phase obs' is set in BNC, the PPP solution will be carried out using both, code and phase observations. A sigma of 5.0 m for code observations and a sigma of 0.02 m for phase observations (defaults) are used to combine both types of observations. As the convergence characteristic of a PPP solution can be influenced by the ratio of the sigmas for code and phase, you may like to introduce you own sigmas for code and phase observations which differ from the default values.
 <ul>
 <li>Introducing a smaller sigma (higher accuracy) for code observations or a larger 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 solutions.</li>
@@ -1488 +1488 @@
 <p><a name="pppsigxyzi"><h4>3.12.8.3 XYZ Init - mandatory</h4></p>
 <p>
-Enter a sigma in meters for the initial XYZ coordinate componentes. A value of 100.0 (default) may be an appropriate choice. However, this value may be significantly smaller (i.e. 0.01) when starting for example from a station with known XZY position in Quick-Start mode.
+Enter a sigma in meters for the initial XYZ coordinate components. A value of 100.0 (default) may be an appropriate choice. However, this value may be significantly smaller (i.e. 0.01) when starting for example from a station with known XZY position in Quick-Start mode.
 </p>
 
@@ -1572 +1572 @@
 <p><a name="combimounttab"><h4>3.13.1 Combination Table - optional</h4></p>
 <p>
-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 stream. Finally, double click on the 'Weight' field to enter a weight to be applied to this stream in the combination. The stream processing can already be startet whith only one corrections stream configured for combination.
+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 stream. Finally, double click on the 'Weight' field to enter a weight to be applied to this stream in the combination. The stream processing can already be started with only one corrections stream configured for combination.
 </p>
 <p>
@@ -1589 +1589 @@
 
 <p>
-The following screenshots describe an example setup of BNC when combining Broadcast Correction streams and upload them to an NTRIP Broadcaster. Note that it requires to specify options under tabs 'Combination' and 'Upload (clk)'. The example uses the combination product to simultaneously carry out an 'INTERNAL' PPP solution in Quickstart mode which allows to monitor 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 upload them to an NTRIP Broadcaster. Note that it requires specifying options under tabs 'Combination' and 'Upload (clk)'. The example uses the combination product to simultaneously carry out an 'INTERNAL' PPP solution in Quickstart mode which allows monitoring the quality of the combination product in the space domain. 
 </p>
 
@@ -1604 +1604 @@
 <p><a name="combimethod"><h4>3.13.1.2 Method - mandatory if 'Combination Table' is populated</h4></p>
 <p>
-Selecet a clock combination method. Available options are Kalman 'Filter' and 'Single-Epoch. It is suggested to use the Kalman Filter approach in case the combined stream of Broadcast Corrections is intended for Precise Point Positioning support.
+Select a clock combination method. Available options are Kalman 'Filter' and 'Single-Epoch. It is suggested to use the Kalman Filter approach in case the combined stream of Broadcast Corrections is intended for Precise Point Positioning support.
 </p>
 
@@ -1617 +1617 @@
 BNC can upload streams carrying orbit and clock corrections to Broadcast Ephemeris in radial, along-track and cross-track components if they are<ol type=a> 
 <li>
-either generated by BNC as a combination of several individual Boradcast Correction streams coming from an number of real-time Analysis Centers (ACs), see section 'Combination',</li>
+either generated by BNC as a combination of several individual Broadcast Correction streams coming from an number of real-time Analysis Centers (ACs), see section 'Combination',</li>
 <li>
 or generated by BNC because the program receives an ASCII stream of precise satellite orbits and clocks via IP port from a connected real-time GNSS engine. Such a stream would be expected in a plain ASCII format and the associated 'decoder' string would have to be 'RTNET'. </li>
@@ -1630 +1630 @@
 <li>Calculate X,Y,Z coordinates from Broadcast Ephemeris orbits. </li>
 <li>Calculate differences dX,dY,dZ between Broadcast Ephemeris and IGS08 orbits. </li>
-<li>Tranform these differences into radial, along-track and cross-track corrections to Broadcast Ephemeris orbits. </li>
+<li>Transform these differences into radial, along-track and cross-track corrections to Broadcast Ephemeris orbits. </li>
 <li>Calculate corrections to Broadcast Ephemeris clocks as differences between Broadcast Ephemeris and IGS08 clocks. </li>
 <li>Encode Broadcast Ephemeris clock and orbit corrections in RTCM Version 3 format. </li>
@@ -1641 +1641 @@
 </p>
 <p>
-BNC requires GNSS clocks and orbits in the IGS Earth-Centered-Earth-Fixed (ECEF) reference system and in a specific ASCII format. The clocks and orbits must be referred to satellite Center of Mass (CoM) and must not containing the conventional periodic relativistic effect. They may be provided by a real-time GNSS engine such as RTNet. The sampling rate for data transmission should not exceed 15 sec. Note that otherwise tools involved in IP streaming such as NTRIP Broadcasters or NTRIP Clients may respond with a timeout.
+BNC requires GNSS clocks and orbits in the IGS Earth-Centered-Earth-Fixed (ECEF) reference system and in a specific ASCII format. The clocks and orbits must be referred to satellite Center of Mass (CoM) and must not contain the conventional periodic relativistic effect. They may be provided by a real-time GNSS engine such as RTNet. The sampling rate for data transmission should not exceed 15 sec. Note that otherwise tools involved in IP streaming such as NTRIP Broadcasters or NTRIP Clients may respond with a timeout.
 </p>
 
@@ -1716 +1716 @@
 <p><a name="upsystem"><h4>3.14.3 System - mandatory if 'Host' is set</h4></p>
 <p>
-BNC allows to configure several Broadcast Correction streams for upload so that they refere to different reference systems and different NTRIP Broadcasters. You may use this functionality for parallel support of a backup NTRIP Broadcaster or for simultaneous support of several reference systems. Available options for referring clock and orbit corrections to specific target reference systems are
+BNC allows to configure several Broadcast Correction streams for upload so that they refer to different reference systems and different NTRIP Broadcasters. You may use this functionality for parallel support of a backup NTRIP Broadcaster or for simultaneous support of several reference systems. Available options for referring clock and orbit corrections to specific target reference systems are
 <p>
 <ul>
 <li>IGS08 which stands for the GNSS-based IGS realization of the International Terrestrial Reference Frame 2008 (ITRF2008), and</li>
-<li>ETRF2000 which stands for the European Terestrial Reference Frame 2000 adopted by EUREF, and</li>
+<li>ETRF2000 which stands for the European Terrestrial Reference Frame 2000 adopted by EUREF, and</li>
 <li>NAD83 which stands for the North American Datum 1983 as adopted for the U.S.A., and</li>
 <li>GDA94 which stands for the Geodetic Datum Australia 1994 as adopted for Australia, and</li>
@@ -1730 +1730 @@
 
 <p>
-BNC only transforms the original IGS08 <u>orbits</u> in the Broadcast Corrections stream to a target reference system while leaving the clocks unchanged. From a theoretical point of view this leads to inconsistencies between orbits and clocks and is therefore not allowed. However, it has been shown by Huisman et al. 2012 that as long as involved scale parameters are small enough, this way of transforming corrections stream contents only leads to hight biases less than about one centimeter. With regards to the systems listed above, the approach has therefore been implemented in BNC for practical reasons.
-</p>
-<p>
-The transformation to GDA94 is an exception in this because it involves a ten times higher scale parameter compared to the other transformation implementations. Note that hence the resulting hight biases for a BNC-transformed GDA94 corrections stream can increase up to about 10 centimeters.
+BNC only transforms the original IGS08 <u>orbits</u> in the Broadcast Corrections stream to a target reference system while leaving the clocks unchanged. From a theoretical point of view this leads to inconsistencies between orbits and clocks and is therefore not allowed. However, it has been shown by Huisman et al. 2012 that as long as involved scale parameters are small enough, this way of transforming corrections stream contents only leads to height biases less than about one centimeter. With regards to the systems listed above, the approach has therefore been implemented in BNC for practical reasons.
+</p>
+<p>
+The transformation to GDA94 is an exception in this because it involves a ten times higher scale parameter compared to the other transformation implementations. Note that hence the resulting height biases for a BNC-transformed GDA94 corrections stream can increase up to about 10 centimeters.
 </p>
 
@@ -1741 +1741 @@
 
 <p>
-<u>ETRF2000:</u> The formulars for the transformation 'ITRF2005-&gt;ETRF2000' are taken from 'Claude Boucher and Zuheir Altamimi 2008: Specifications for reference frame fixing in the analysis of EUREF GPS campaign', see <u>http://etrs89.ensg.ign.fr/memo-V8.pdf</u>. The following 14 Helmert Transformation Parameters were introduced:
+<u>ETRF2000:</u> The formulas for the transformation 'ITRF2005-&gt;ETRF2000' are taken from 'Claude Boucher and Zuheir Altamimi 2008: Specifications for reference frame fixing in the analysis of EUREF GPS campaign', see <u>http://etrs89.ensg.ign.fr/memo-V8.pdf</u>. The following 14 Helmert Transformation Parameters were introduced:
 </p>
 <p>
@@ -1764 +1764 @@
 
 <p>
-<u>NAD83:</u> Formulars for the transformation 'ITRF2005-&gt;NAD83' are taken from 'Chris Pearson, Robert McCaffrey, Julie L. Elliott, Richard Snay 2010: HTDP 3.0: Software for Coping with the Coordinate Changes Associated with Crustal Motion, Journal of Surveying Engineering'.
+<u>NAD83:</u> Formulas for the transformation 'ITRF2005-&gt;NAD83' are taken from 'Chris Pearson, Robert McCaffrey, Julie L. Elliott, Richard Snay 2010: HTDP 3.0: Software for Coping with the Coordinate Changes Associated with Crustal Motion, Journal of Surveying Engineering'.
 </p>
 <p>
@@ -1787 +1787 @@
 
 <p>
-<u>GDA94:</u> The formulars for the transformation 'ITRF2000-&gt;GDA94' are taken from 'John Dawson, Alex Woods 2010: ITRF to GDA94 coordinate transformations', Journal of Applied Geodesy, 4 (2010), 189¿199, de Gruyter 2010. DOI 10.1515/JAG.2010.019'.
+<u>GDA94:</u> The formulas for the transformation 'ITRF2000-&gt;GDA94' are taken from 'John Dawson, Alex Woods 2010: ITRF to GDA94 coordinate transformations', Journal of Applied Geodesy, 4 (2010), 189¿199, de Gruyter 2010. DOI 10.1515/JAG.2010.019'.
 </p>
 <p>
@@ -1810 +1810 @@
 
 <p>
-<u>SIRGAS2000:</u> The formulars for the transformation 'ITRF2005-&gt;SIRGAS2000' were provided via personal communication from CGED-Coordenacao de Geodesia, IBGE/DGC - Diretoria de Geociencias, Brazil.</u>.
+<u>SIRGAS2000:</u> The formulas for the transformation 'ITRF2005-&gt;SIRGAS2000' were provided via personal communication from CGED-Coordenacao de Geodesia, IBGE/DGC - Diretoria de Geociencias, Brazil.</u>.
 </p>
 <p>
@@ -1833 +1833 @@
 
 <p>
-<u>SIRGAS95:</u> The formulars for the transformation 'ITRF2005-&gt;SIRGAS95' were provided via personal communication from Gustavo Acuha, Laboratorio de Geodesia Fisica y Satelital at Zulia University (LGFS-LUZ), parameters based on values from Table 4.1 of "Terrestrial Reference Frames (April 10, 2009), Chapter 4" in http://tai.bipm.org/iers/convupdt/convupdt_c4.html.</u>.
+<u>SIRGAS95:</u> The formulas for the transformation 'ITRF2005-&gt;SIRGAS95' were provided via personal communication from Gustavo Acuha, Laboratorio de Geodesia Fisica y Satelital at Zulia University (LGFS-LUZ), parameters based on values from Table 4.1 of "Terrestrial Reference Frames (April 10, 2009), Chapter 4" in http://tai.bipm.org/iers/convupdt/convupdt_c4.html.</u>.
 </p>
 <p>
@@ -1902 +1902 @@
 
 <p>
-The following screenshot shows the encoding and uploading of a stream of precise orbits and clocks coming form a real-time engine in 'RTNET' ASCII format. The stream is uploaded to NTRIP Broadcaster 'products.igs-ip.net'. It is referred to APC and IGS08. Uploaded data are locally saved in SP3 and Clock RINEX format. Required Broadcast Ephemeris are received via stream 'RTCM3EPH'.
+The following screenshot shows the encoding and uploading of a stream of precise orbits and clocks coming from a real-time engine in 'RTNET' ASCII format. The stream is uploaded to NTRIP Broadcaster 'products.igs-ip.net'. It is referred to APC and IGS08. Uploaded data are locally saved in SP3 and Clock RINEX format. Required Broadcast Ephemeris are received via stream 'RTCM3EPH'.
 </p>
 <p><img src="IMG/screenshot26.png"/></p>
@@ -1961 +1961 @@
 </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 a 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 messages.
+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 messages.
 <br>If NMEA-GGA messages 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 most 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..
@@ -1983 +1983 @@
 <p><a name="logs"><h4>3.17. Logging</h4></p>
 <p>
-A tabs section on the bottom of the main window provides online control of BNC's activities. Tabs are available to show the records saved in a logfile, for a plot to control the bandwidth consumtion, for a plot showing stream latencies, and for time series plots of PPP results.
+A tabs section on the bottom of the main window provides online control of BNC's activities. Tabs are available to show the records saved in a logfile, for a plot to control the bandwidth consumption, for a plot showing stream latencies, and for time series plots of PPP results.
 </p>
 <p><a name="logfile"><h4>3.17.1 Log</h4></p>
@@ -2008 +2008 @@
 <p><a name="ppptab"><h4>3.17.4 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 'Origin' option is defined. 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 coordiate components.
+Precise Point Positioning time series of North (red), East (green) and Up (blue) coordinate components are shown in the 'PPP Plot' tab when a 'Origin' option is defined. 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 components.
 </p>
 
@@ -2049 +2049 @@
 <p><a name="gettable"><h4>3.18.1.4 Get Table</h4></p>
 <p>
-Use the 'Get Table' button to download the source-table from the NTRIP Broadcaster. Pay attention to data fields 'format' and 'format-details'. Keep in mind that BNC can only decode and convert streams that come in RTCM Version 2, RTCM Version 3, or RTNET format. For access to observations, ephemeris or ephemris correctiors, an RTCM Version 2 streams must contain message types 18 and 19 or 20 and 21 while an RTCM Version 3 streams must contain
+Use the 'Get Table' button to download the source-table from the NTRIP Broadcaster. Pay attention to data fields 'format' and 'format-details'. Keep in mind that BNC can only decode and convert streams that come in RTCM Version 2, RTCM Version 3, or RTNET format. For access to observations, ephemeris or ephemeris corrections, an RTCM Version 2 streams must contain message types 18 and 19 or 20 and 21 while an RTCM Version 3 streams must contain
 <ul>
 <li>GPS or SBAS message types 1002 or 1004, or</li>
@@ -2097 +2097 @@
 <p><a name="map"><h4>3.18.1.6 Map - optional</h4></p>
 <p>
-Button 'Map' opens a window to show a distribution map of the casters's streams. You may like to zoom in or out using option 'Zoom +' or 'Zoom -'. You may also like to 'Clean' or 'Reset' a map or let it 'Fit' exactly to the current size of the window. Option 'Close' shuts the window.
+Button 'Map' opens a window to show a distribution map of the casters' streams. You may like to zoom in or out using option 'Zoom +' or 'Zoom -'. You may also like to 'Clean' or 'Reset' a map or let it 'Fit' exactly to the current size of the window. Option 'Close' shuts the window.
 </p>
 
@@ -2113 +2113 @@
 </p>
 <p>
-Streams directly received from a TCP/IP port show up with an 'N' for 'No NTRIP' in the 'Streams' canvas section on BNC's main window . Latitude and longitude are to be entered just for informal reasons.
+Streams directly received from a TCP/IP port show up with an 'N' for 'No NTRIP' in the 'Streams' canvas section on BNC's main window. Latitude and longitude are to be entered just for informal reasons.
 <p>
 </p>
@@ -2131 +2131 @@
 </p>
 <p>
-Streams directly received at a UDP port show up with a 'UN' for 'UDP, No NTRIP' in the 'Streams' canvas section on BNC's main window . Latitude and longitude are to be entered just for informal reasons.
+Streams directly received at a UDP port show up with a 'UN' for 'UDP, No NTRIP' in the 'Streams' canvas section on BNC's main window. Latitude and longitude are to be entered just for informal reasons.
 <p>
 
@@ -2216 +2216 @@
 
 <p><a name="conffile"><h4>3.19.3 Configuration File - optional</h4></p>
-The default configuration file name is 'BNC.ini'. You may change this name at startup time using the command line option '--conf &lt;<u>confFileName</u>&gt;'. This allows to run several BNC jobs in parallel on the same host using different sets of configuration options. <u>confFileName</u> stands either for the full path to a configuration file or just for a file name. If you introduce only a filename, the corresponding file will be saved in the current working directory from where BNC is started.
+The default configuration file name is 'BNC.ini'. You may change this name at startup time using the command line option '--conf &lt;<u>confFileName</u>&gt;'. This allows running several BNC jobs in parallel on the same host using different sets of configuration options. <u>confFileName</u> stands either for the full path to a configuration file or just for a file name. If you introduce only a filename, the corresponding file will be saved in the current working directory from where BNC is started.
 </p>
 <p>
@@ -2301 +2301 @@
 Zdenek Lukes, Czech Technical University Prague, Department of Geodesy, extended the RTCM Version 2 decoder to handle message types 3, 20, 21, and 22 and added loss of lock indicator.<br>
 Jan Dousa, Geodetic Observatory Pecny, Czech Republic, provided a tool for drawing stream distribution maps and also helped with fixing bugs.<br>
-Denis Laurichesse, Centre National d'Etudes Spatiales (CNES), suggested to synchronize observations and clock corrections to reduce high frequency noise in PPP solutions.
+Denis Laurichesse, Centre National d'Etudes Spatiales (CNES), suggested synchronizing observations and clock corrections to reduce high frequency noise in PPP solutions.
 </p>
 
@@ -2352 +2352 @@
 <tr>
 <td>Dec 2008 &nbsp;</td><td>Version 1.6 &nbsp;</td>
-<td>[Mod] Fill blanc columns in RINEXv3 with 0.000<br> [Add] RTCMv3 decoder for clock and orbit corrections<br>[Add] Check RTCMv3 streams for incoming message types<br> [Add] Decode RTCMv2 message types 3, 20, 21, and 22<br> [Add] Loss of lock and lock time indicator<br> [Bug] Rounding error in RTCMv3 decoder concerning GLONASS height<br> [Mod] Accept GLONASS in RTCMv3 when transmitted first<br> [Add] Leap second 1 January 2009<br> [Add] Offline mode, read data from file<br> [Add] Output antenna descriptor, coordinates and excentricities from RTCMv3<br> [Add] Reconfiguration on-the-fly<br> [Mod] Binary output of synchronized observations<br> [Add] Binary output of unsynchronized observations<br> [Bug] Fixed problem with joined RTCMv3 blocks</td>
+<td>[Mod] Fill blanc columns in RINEXv3 with 0.000<br> [Add] RTCMv3 decoder for clock and orbit corrections<br>[Add] Check RTCMv3 streams for incoming message types<br> [Add] Decode RTCMv2 message types 3, 20, 21, and 22<br> [Add] Loss of lock and lock time indicator<br> [Bug] Rounding error in RTCMv3 decoder concerning GLONASS height<br> [Mod] Accept GLONASS in RTCMv3 when transmitted first<br> [Add] Leap second 1 January 2009<br> [Add] Offline mode, read data from file<br> [Add] Output antenna descriptor, coordinates and eccentricities from RTCMv3<br> [Add] Reconfiguration on-the-fly<br> [Mod] Binary output of synchronized observations<br> [Add] Binary output of unsynchronized observations<br> [Bug] Fixed problem with joined RTCMv3 blocks</td>
 </tr>
 
@@ -2397 +2397 @@
 <tr>
 <td>Feb 2011 &nbsp;</td><td>Version 2.5 &nbsp;</td>
-<td>[Add] PPP option for sync of clock observations and corrections<br> [Add] Drafted RTCMv3 Galileo ephemeris messages 1045<br> [Add] Drafted RTCMv3 Multipe Signal Messages<br> [Add] Optional specification of sigmas for coordinates and troposphere in PPP<br> [Add] Include Galileo in SPP<br> [Add] Include Galileo observations in output via IP port<br> [Add] Include Galileo observations in output via RINEXv3 files<br> [Mod] Interface format for feeding a real-time engine with observations<br> [Add] Correct observations for antenna phase center offsets<br> [Add] Combine orbit/clock correction streams<br> [Add] Specify corrections mountpoint in PPP tab</td>
+<td>[Add] PPP option for sync of clock observations and corrections<br> [Add] Drafted RTCMv3 Galileo ephemeris messages 1045<br> [Add] Drafted RTCMv3 Multiple Signal Messages<br> [Add] Optional specification of sigmas for coordinates and troposphere in PPP<br> [Add] Include Galileo in SPP<br> [Add] Include Galileo observations in output via IP port<br> [Add] Include Galileo observations in output via RINEXv3 files<br> [Mod] Interface format for feeding a real-time engine with observations<br> [Add] Correct observations for antenna phase center offsets<br> [Add] Combine orbit/clock correction streams<br> [Add] Specify corrections mountpoint in PPP tab</td>
 </tr>
 
 <tr>
 <td>Apr 2011 &nbsp;</td><td>Version 2.6 &nbsp;</td>
-<td>[Add] Complete integration of BNS in BNC<br> [Add] SP3 and Clock RINEX output<br> [Add] PPP in Post Processing Mode<br> [Add] Some RINEX editing & QC functionality<br> [Add] Threshold for orbit outliers in combination solution<br> [Add] Real-time engine becomes orbit/clock server instead of client<br> [Mod] 'EOE' added to orbit/clock stream from engine<br> [Add] Correction for antenna excentricities<br> [Add] Quick start mode for PPP<br> [Mod] Design of format for feeding engine changed to follow RINEX v3<br> [Mod] Implementation of SSR message encoding modified according to standard<br> [Add] SSL/TLS Support of Ntrip Version 2<br> [Mod] Switch to Qt version 4.7.3<br> [Add] RINEX editing, concatenation and quality check<br> [Mod] RTCMv3 Galileo Broadcast Ephemeris message 1045</td>
+<td>[Add] Complete integration of BNS in BNC<br> [Add] SP3 and Clock RINEX output<br> [Add] PPP in Post Processing Mode<br> [Add] Some RINEX editing & QC functionality<br> [Add] Threshold for orbit outliers in combination solution<br> [Add] Real-time engine becomes orbit/clock server instead of client<br> [Mod] 'EOE' added to orbit/clock stream from engine<br> [Add] Correction for antenna eccentricities<br> [Add] Quick start mode for PPP<br> [Mod] Design of format for feeding engine changed to follow RINEX v3<br> [Mod] Implementation of SSR message encoding modified according to standard<br> [Add] SSL/TLS Support of Ntrip Version 2<br> [Mod] Switch to Qt version 4.7.3<br> [Add] RINEX editing, concatenation and quality check<br> [Mod] RTCMv3 Galileo Broadcast Ephemeris message 1045</td>
 </tr>
 
@@ -2475 +2475 @@
 </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 to use 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 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>
 
@@ -2665 +2665 @@
 <tr><td>pppRefCrdY=</td><td>PPP Client: Y coordinate of plot origin</td></tr>
 <tr><td>pppRefCrdZ=</td><td>PPP Client: Z coordinate of plot origin</td></tr>
-<tr><td>pppRefdN=</td><td>PPP Client: North excentricity</td></tr>
-<tr><td>pppRefdE=</td><td>PPP Client: East excentricity</td></tr>
-<tr><td>pppRefdU=</td><td>PPP Client: Up excentricity</td></tr>
+<tr><td>pppRefdN=</td><td>PPP Client: North eccentricity</td></tr>
+<tr><td>pppRefdE=</td><td>PPP Client: East eccentricity</td></tr>
+<tr><td>pppRefdU=</td><td>PPP Client: Up eccentricity</td></tr>
 <tr><td>nmeaFile=</td><td>PPP Client: NMEA outputfile</td></tr>
 <tr><td>nmeaPort=</td><td>PPP Client: NMEA IP output port</td></tr>