Changeset 1035 in ntrip for trunk/BNC/bnchelp.html

Timestamp:

Aug 15, 2008, 6:31:34 PM (17 years ago)

Author:

weber

Message:

* empty log message *

File:

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

trunk/BNC/bnchelp.html

@@ -95 +95 @@
 &nbsp; &nbsp; &nbsp; 3.8.3. <a href=#corrport>Port</a><br>
 &nbsp; &nbsp; &nbsp; 3.8.4. <a href=#corrwait>Wait for Full Epoch</a><br>
+&nbsp; &nbsp; &nbsp; 3.8.5. <a href=#corrlate>Latency Log</a><br>
 3.9. <a href=#advnote>Monitor</a><br>
 &nbsp; &nbsp; &nbsp; 3.9.1. <a href=#obsrate>Observation Rate</a><br>
@@ -476 +477 @@
 <p><a name="corrwait"><h4>3.8.4 Wait for Full Epoch - mandatory if 'Port' is set</h4></p>
 <p>
-When feeding a real-time GNSS engine waiting for Ephemeris Corrections, BNC drops whatever is received later than 'Wait for full epoch' seconds. A value of 2 to 5 seconds could be an appropriate choice for that, depending on the latency of the incoming Ephemeris Corrections stream and the delay acceptable by your application. Default value for 'Wait for full epoch' is '0' seconds meaning that BNC will output whatever becomes available immediately and not drop any Ephemeris Correction.
+When feeding a real-time GNSS engine waiting for Ephemeris Corrections, BNC drops (only concering IP port output) whatever is received later than 'Wait for full epoch' seconds. A value of 2 to 5 seconds could be an appropriate choice for that, depending on the latency of the incoming Ephemeris Corrections stream and the delay acceptable by your application.
+</p>
+<p><a name="corrlate"><h4>3.8.5 Latency Log - optional</h4></p>
+<p>
+Message latencies are logged for streams carrying orbit and clock corrections to Broadcast Ephemeris if option 'Latency log' is ticked.
 </p>
 
@@ -564 +569 @@
 </pre>
 <p>
- BNC can average the latencies per stream over a certain period of GPS time, the 'Performance log' interval. Mean latencies are calculated from the individual latencies of at most one (first incoming) observation per second. Note that computing correct latencies requires the clock of the host computer to be properly synchronized.
+ BNC can average the latencies of observations per stream over a certain period of GPS time, the 'Performance log' interval. Mean latencies are calculated from the individual latencies of at most one (first incoming) observation per second. Note that computing correct latencies requires the clock of the host computer to be properly synchronized.
 </p>
 <p>
@@ -570 +575 @@
 </p>
 <p>
-Latencies and statistical information can be recorded in the Log file/section at the end of each 'Performance log' interval. A typical output from a 1 hour 'Performance log' interval would be:
+Latencies of observations and statistical information can be recorded in the Log file/section at the end of each 'Performance log' interval. A typical output from a 1 hour 'Performance log' interval would be:
 </p>
 <pre>
@@ -586 +591 @@
 <p><a name="messmount"><h4>3.10.1 Mountpoint - optional</h4></p>
 <p>
-Specify the mountpoint of an RTCM Version 3.x stream to log the numbers of incoming message types. Logged time stamps refer to message reception time and allow to understand repetition rates. Enter 'ALL' if you want to log message type numbers of all configured streams. Beware that the size of the logfile can rapidly increase depending on the number of incoming RTCM Version 3.x streams.
+Specify the mountpoint of an RTCM Version 3.x stream to log the numbers of incoming message types. Logged time stamps refer to message reception time and allow to understand repetition rates. Enter 'ALL' if you want to log message type numbers of all configured streams. Beware that the size of the logfile can rapidly increase depending on the number of incoming RTCM Version 3.x 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 carried in RTCM Version 3.x streams.