Index: trunk/BNC/bnchelp.html
===================================================================
--- trunk/BNC/bnchelp.html	(revision 4202)
+++ trunk/BNC/bnchelp.html	(revision 4203)
@@ -1414,5 +1414,5 @@
 </p>
 <p>
-Once XYZ coordinate components are defined, the 'PPP' line in BNC's logfile is extended by Nort, East and Up displacements to (example):
+Once a XYZ coordinate is defined, the 'PPP' line in BNC's logfile is extended by Nort, East and Up displacements to (example):
 </p>
 <pre>
@@ -1569,10 +1569,10 @@
 <p><a name="pppquick"><h4>3.12.7.7 Quick-Start - optional if XYZ is set</h4></p>
 <p>
-Enter the lenght of a startup period in seconds for which you want to fix the PPP solution to a known XYZ coordinate. Constraining coordinate components is done in BNC through setting the 'XYZ 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 know position throughout the defined period. A value of 120 (default) is likely to be an appropriate choice for 'Quick-Start'
-<p>
-You may need to create your own reference coordinate through running BNC for an hour in normal mode before applying the Quick-Start option. Don't forget to introduce a realistic sigma 'XYZ Ini' according to the coordinate's precision.
+Enter the lenght of a startup period in seconds for which you want to fix the PPP solution to a known XYZ coordinate. Constraining coordinates is done in BNC through setting the 'XYZ 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 know position throughout the defined period. A value of 60 is likely to be an appropriate choice for 'Quick-Start'. 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 through running BNC for an hour in normal mode before applying the 'Quick-Start' option. Don't forget to introduce a realistic sigma 'XYZ Ini' according to the coordinate's precision.
 </p>
 
@@ -1585,8 +1585,8 @@
 <p><a name="pppgap"><h4>3.12.7.8 Maximal Solution Gap - optional if Quick-Start is set</h4></p>
 <p>
-Specify a 'Maximum Solution Gap' in seconds. Should the time span between two consecutive solutions exceed this limit, the algorithm returns into the Quick-Start mode and fixes the introduced reference coordinate for the specified Quick-Start period. A value of '120' seconds could be an appropriate choice.
-</p>
-<p>
-This option makes only sense for a stationary operated receiver where solution convergence can be enforced because a good approximation for the rover position is known. Default is an empty option field, meaning that you don't want BNC to return into the Quick-Start mode after failures caused i.e. by longer lasting outages.
+Specify a 'Maximum Solution Gap' in seconds. Should the time span between two consecutive solutions exceed this limit, the algorithm returns into the 'Quick-Start' mode and fixes the introduced reference coordinate for the specified 'Quick-Start' period. A value of '60' seconds could be an appropriate choice.
+</p>
+<p>
+This option makes only sense for a stationary operated receiver where solution convergence can be enforced because a good approximation for the rover position is known. Default is an empty option field, meaning that you don't want BNC to return into the 'Quick-Start' mode after failures caused i.e. by longer lasting outages.
 </p>
 
@@ -1598,12 +1598,12 @@
 <p><a name="pppsigc"><h4>3.12.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 (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>
+When 'Use phase obs' is set in BNC, the PPP solution will be carried out using both, code and phase observations. A sigma of 10.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 solution.</li>
 <li>Introducing a larger 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>
 </p>
 <p>
-Specify a sigma for code observations. Default is 5.0 m.
+Specify a sigma for code observations. Default is 10.0 m.
 </p>
 
@@ -1615,10 +1615,10 @@
 <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 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.
+Enter a sigma in meters for the initial XYZ coordinate. 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>
 
 <p><a name="pppsigxyzn"><h4>3.12.8.4 XYZ White Noise - mandatory</h4></p>
 <p>
-Enter a sigma in meters for the 'White Noise' of estimated XYZ coordinate components. A value of 100.0 (default) may be appropriate considering the potential movement of a rover.
+Enter a sigma in meters for the 'White Noise' of estimated XYZ coordinate components. A value of 100.0 (default) may be appropriate when considering possible sudden movements of a rover.
 </p>
 
@@ -1635,5 +1635,5 @@
 <p><a name="combi"><h4>3.13. Combine Corrections</h4></p>
 <p>
-BNC allows to process several orbit and clock corrections streams in real-time to produce, encode, upload and save a combination of Broadcast Corrections from various providers. It is so far only the satellite clock corrections which are combined while orbit corrections in the combination product as well as the product update rates are just taken over from one of the incoming Broadcast Correction streams. Combining only clock corrections using a fixed orbit reference has the possibility to introduce some analysis inconsistencies. We may therefore eventually consider improvements on this approach. The clock combination can be based either on a plain 'Single-Epoch' or on a 'Kalman' Filter approach.
+BNC allows to process several orbit and clock correction streams in real-time to produce, encode, upload and save a combination of Broadcast Corrections from various providers. It is so far only the satellite clock corrections which are combined while orbit corrections in the combination product as well as the product update rates are just taken over from one of the incoming Broadcast Correction streams. Combining only clock corrections using a fixed orbit reference has the possibility to introduce some analysis inconsistencies. We may therefore eventually consider improvements on this approach. The clock combination can be based either on a plain 'Single-Epoch' or on a 'Kalman' Filter approach.
 </p>
 <p>
@@ -1647,5 +1647,5 @@
 In view of IGS real-time products, the 'Combine Corrections' functionality has been integrated in BNC because
 <ul>
-<li>the software with its Graphic User Interface and wide range of supported Operation Systems represents a perfect platform to process many Broadcast Correction streams in parallel;</li>
+<li>the software with its Graphic User Interface and wide range of supported Operating Systems represents a perfect platform to process many Broadcast Correction streams in parallel;</li>
 <li>outages of single AC product streams can be mitigated through merging several incoming streams into a combined product;</li>
 <li>generating a combination product from several AC products allows detecting and rejecting outliers;</li> 
@@ -1653,10 +1653,13 @@
 <li>an individual AC could prefer to disseminate a stream combined from primary and backup IT resources to reduce outages;</li>
 <li>it enables a BNC PPP user to follow his own preference in combining streams from individual ACs for Precise Point Positioning;</li>
-<li>it allows an instantaneous quality control of the combination process not only in the time domain but also in the space domain; this can be done through direct application of the combination stream in a PPP solution even without prior stream upload to an NTRIP Broadcaster;</li>
-<li>it provides the means to output SP3 files containing precise orbit and clock information for further processing using other tools than BNC.</li>
-</ul>
-</p>
-<p>
-Note that the combination process requires real-time access to Broadcast Ephemeris. So, in addition to the orbit and clock corrections 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.
+<li>it allows an instantaneous quality control of the combination process not only in the time domain but also in the space domain; this can be done through direct application of the combined stream in a PPP solution even without prior upload to an NTRIP Broadcaster;</li>
+<li>it provides the means to output SP3 and Clock RINEX files containing precise orbit and clock information for further processing using other tools than BNC.</li>
+</ul>
+</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.
+</p>
+<p>
+Note further that you need to tick the 'Use GLONASS' option which is part ot the 'PPP (2)' panel in case you want to produce an GPS plus GLONASS combination.
 </p>
 <p>
@@ -1664,8 +1667,5 @@
 </p>
 <p>
-Note further that you need to tick the 'Use GLONASS' option which is part ot the 'PPP (2)' panel in case you want to produce an GPS plus GLONASS combination.
-</p>
-<p>
-With respect to IGS, it is important to understand that a major effect in the combination of GNSS orbit and clock corrections 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>
@@ -1673,5 +1673,5 @@
 </p>
 <p>
-The following recursive algorithm is used to detect orbit outliers in the Kalman Filter combination when corrections are provided by several ACs:
+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.
@@ -1683,7 +1683,7 @@
 Step 4: We find the greatest difference between AC specific and mean satellite positions.
 <br>
-Step 5: If that is less than 0.2 m 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 don't have an outlier and can proceed to the next epoch.
 <br>
-Step 6: If that is greater 0.2 m then corrections of the affiliated AC are ignored for the affected epoch and the outlier detection restarts with step 1.
+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.
 </p>
 <p>
@@ -1691,8 +1691,5 @@
 </p>
 <p>
-Note further that the combination procedure in BNC also - formally - works with only one Broadcast Corrections stream specified for combination. 
-</p>
-<p>
-The part of BNC which enables the combination of orbit and clock corrections streams is not intended for publication under GNU General Public License (GPL). However, pre-compiled BNC binaries which support the 'Combine Corrections' option will be available for personal usage.
+The part of BNC which enables the combination of Broadcast Corrections is not intended for publication under GNU General Public License (GPL). However, pre-compiled BNC binaries which support the 'Combine Corrections' option are made available.
 </p>
 
@@ -1702,22 +1699,22 @@
 </p>
 <p>
-Note that an appropriate 'Wait for full corr epoch' value needs to be specified for the combination under the 'Broadcast Corrections' tab. To give an example: a value of '15' sec would make sense if the update rate of incoming clock corrections is 10 sec.
-</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>
-<p>
-Default is an empty 'Combine Corrections Table' meaning that you don't want BNC to combine orbit and clock corrections streams.
-</p>
-<p>
-It is possible to specify only one Broadcast Ephemeris corrections 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' tab.
+Note that an appropriate 'Wait for full corr epoch' value needs to be specified for the combination under the 'Broadcast Corrections' tab. To give an example: a value of 15 sec would make sense if the update rate of incoming clock corrections is 10 sec.
+</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>
+<p>
+Default is an empty 'Combine Corrections' table meaning that you don't want BNC to combine orbit and clock correction streams.
+</p>
+<p>
+It is possible to specify only one Broadcast Ephemeris corrections 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' tab.
 </p>
 
 <p><a name="combiadd"><h4>3.13.1.1 Add Row, Delete - optional</h4></p>
 <p>
-Hit 'Add Row' button to add another row to the 'Combine Corrections Table' or hit the 'Delete' button to delete the highlighted row(s).
-</p>
-
-<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 specifying options under tabs 'Combine Corrections' and 'Upload Corrections'. 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. 
+Hit 'Add Row' button to add another row to the 'Combine Corrections' table or hit the 'Delete' button to delete the highlighted row(s).
+</p>
+
+<p>
+The following screenshots describe an example setup of BNC when combining Broadcast Correction streams and uploading them to an NTRIP Broadcaster. Note that it requires specifying options under tabs 'Combine Corrections' and 'Upload Corrections'. The example uses the combination product to simultaneously carry out an 'INTERNAL' PPP solution in 'Quick-Start' mode which allows monitoring the quality of the combination product in the space domain. 
 </p>
 
@@ -1732,10 +1729,10 @@
 <p><u>Figure 17:</u> 'INTERNAL' PPP with BNC using combined Broadcast Corrections stream.</p>
 
-<p><a name="combimethod"><h4>3.13.1.2 Method - mandatory if 'Combine Corrections Table' is populated</h4></p>
-<p>
-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>
-
-<p><a name="combimax"><h4>3.13.1.3 Maximal Residuum - mandatory if 'Combine Corrections Table' is populated</h4></p>
+<p><a name="combimethod"><h4>3.13.1.2 Method - mandatory if 'Combine Corrections' table is populated</h4></p>
+<p>
+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.
+</p>
+
+<p><a name="combimax"><h4>3.13.1.3 Maximal Residuum - mandatory if 'Combine Corrections' table is populated</h4></p>
 
 <p>BNC combines all incoming clocks according to specified weights. Individual clock estimates that differ by more than 'Maximal Residuum' meters from the average of all clocks will be ignored.<p>
@@ -1743,5 +1740,5 @@
 <p>Default is a 'Maximal Residuum' of 999.0 meters</p>
 
-<p><a name="combismpl"><h4>3.13.1.4 Sampling - mandatory if 'Combine Corrections Table' is populated</h4></p>
+<p><a name="combismpl"><h4>3.13.1.4 Sampling - mandatory if 'Combine Corrections' table is populated</h4></p>
 <p>Specify a combination sampling interval. Clock and orbit corrections will be produced following that interval. A value of 10 sec may be an appropriate choice.</p>
 
@@ -1753,9 +1750,9 @@
 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 'Combine Corrections',</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>
+or generated by BNC while 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', see format description below. </li>
 </ol>
 The procedure taken by BNC to generate the clock and orbit corrections to Broadcast Ephemeris and upload them to an NTRIP Broadcaster is as follow:
 <ul>
-<li>Continuously receive up-to-date Broadcast Ephemeris carrying approximate orbits and clocks for all satellites. Read new Broadcast Ephemeris immediately whenever they become available. This information may come via a stream of RTCM messages generated from a BNC instance.</li>
+<li>Continuously receive up-to-date Broadcast Ephemeris carrying approximate orbits and clocks for all satellites. Read new Broadcast Ephemeris immediately whenever they become available. This information may come via a stream of RTCM messages generated from another BNC instance.</li>
 </ul>
 Then, epoch by epoch: 
@@ -1765,7 +1762,7 @@
 <li>Calculate differences dX,dY,dZ between Broadcast Ephemeris and IGS08 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>Calculate corrections to Broadcast Ephemeris clocks as differences between Broadcast Ephemeris clocks and IGS08 clocks. </li>
 <li>Encode Broadcast Ephemeris clock and orbit corrections in RTCM Version 3 format. </li>
-<li>Upload corrections stream to NTRIP Broadcaster. </li>
+<li>Upload Broadcast Corrections stream to NTRIP Broadcaster. </li>
 </ul>
 <p>
@@ -2014,5 +2011,5 @@
 </p>
 <p>
-In case the 'Combine Corrections Table' contains only one Broadcast Corrections stream, BNC will merge that stream with Broadcast Ephemeris to save results in files specified here through SP3 and/or Clock RINEX file path. In such a case you have to define only the SP3 and Clock RINEX file path and no further options in the 'Upload Corrections' table.
+In case the 'Combine Corrections' table contains only one Broadcast Corrections stream, BNC will merge that stream with Broadcast Ephemeris to save results in files specified here through SP3 and/or Clock RINEX file path. In such a case you have to define only the SP3 and Clock RINEX file path and no further options in the 'Upload Corrections' table.
 </p>
 
@@ -2767,9 +2764,9 @@
 <br>
 <li>File 'QuickStartPPP.bnc'<br>
-The purpose of this configuration is Precise Point Positioning in QuickStart mode from observations of a static receiver with precisely known position. The configuration reads RTCM Version 3 observations, orbit and clock correctors and a Broadcast Ephemeris stream. Positions are saved in NMEA format on disc and output through IP port for real-time visualization with tools like RTKNAVI.
+The purpose of this configuration is Precise Point Positioning in Quick-Start mode from observations of a static receiver with precisely known position. The configuration reads RTCM Version 3 observations, orbit and clock correctors and a Broadcast Ephemeris stream. Positions are saved in NMEA format on disc and output through IP port for real-time visualization with tools like RTKNAVI.
 </li>
 <br>
 <li>File 'PPPPostProc.bnc<br>
-The purpose of this configuration is Precise Point Positioning in Post Processing mode. BNC reads a RINEX Observation and a RINEX  Version 3 Navigation files and a Broadcast Corrections files. PPP processing otions are set in support of the QuickStart mode. The output is saved in a specific Post Processing logfile and contains the coordinates derived over time following the implemented PPP filter algorithm.
+The purpose of this configuration is Precise Point Positioning in Post Processing mode. BNC reads a RINEX Observation and a RINEX  Version 3 Navigation files and a Broadcast Corrections files. PPP processing otions are set in support of the Quick-Start mode. The output is saved in a specific Post Processing logfile and contains the coordinates derived over time following the implemented PPP filter algorithm.
 </li>
 <br>
