Changeset 4996 in ntrip

Timestamp:

Mar 24, 2013, 9:22:18 PM (12 years ago)

Author:

weber

Message:

Documentation completed

File:

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

trunk/BNC/src/bnchelp.html

@@ -1115 +1115 @@
 </p>
 <p>
-Any epoch in the output begins with a line containing the GPS week number and the seconds within the GPS week. Following lines begin wiht the mountpoint string of the stream which provides the observations followed by a satellite ID and - in case of GLONASS - a channel number. Observation types are specified by the three character observation code defined in RINEX Version 3. In case of phase observations a Slip Count is added which is set to "-1" if it is not set. The end of an epoch in indicated by an empty line.
-</p>
-
-<p>Note on 'SlipCount':<br>
-It is the current understanding of BNC's authors that different slip counts could be referred to different phase measurements (i.e. L1C and L1P). The 'loss-of-lock' flags in RINEX are an example for making such kind of information available per phase measurement. However, it looks like we do have only one slip count in RTCM Version 3 for all phase measurements. As it could be that a receiver generates different slip counts for different phase measurements, we output one slip count per phase measurement to a listening real-time GNSS network engine.
+Any epoch in the output begins with a line containing the GPS week number and the seconds within the GPS week. Following lines begin with the mountpoint string of the stream which provides the observations followed by a satellite ID and - in case of GLONASS - a channel number. Observation types are specified by the three character observation code defined in RINEX Version 3. In case of phase observations a Slip Count is added which is put to "-1" if it is not set. The end of an epoch in indicated by an empty line.
+</p>
+
+<p>Note on 'Slip Count':<br>
+It is the current understanding of BNC's authors that different Slip Counts could be referred to different phase measurements (i.e. L1C and L1P). The 'loss-of-lock' flags in RINEX are an example for making such kind of information available per phase measurement. However, it looks like we do have only one Slip Count in RTCM Version 3 for all phase measurements. As it could be that a receiver generates different Slip Counts for different phase measurements, we output one Slip Count per phase measurement to a listening real-time GNSS network engine.
 </p>
 
@@ -1962 +1962 @@
 </p>
 <p>
-BNC requires GNSS orbits and clocks in the IGS Earth-Centered-Earth-Fixed (ECEF) reference system and in a specific ASCII format. The orbits and clocks must not contain the conventional periodic relativistic effect. They may be provided by a real-time GNSS engine such as RTNet. The sampling interval 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>
-
-<p>
-Below you find an example of precise orbits and clocks coming in ASCII format (which is named 'RTNET' in this document) from a real-time GNSS engine. Each epoch begins with an asterisk character followed by the time as year, month, day of month, hour, minute and second. Subsequent records provide the following set of parameters for each satellite:
-<p>
-<p>
-&lt;SatelliteID&gt; &lt;key&gt; &lt;numValues&gt; &lt;value1 value2 ...&gt; &lt;key&gt; &lt;numValues&gt; &lt;value1 value2 ...&gt; ... weber
+BNC requires GNSS orbits and clocks in the IGS Earth-Centered-Earth-Fixed (ECEF) reference system and in a specific ASCII format. The orbits and clocks may be provided by a real-time GNSS engine such as RTNet. The sampling interval 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>
+<p>
+Below you find an example of precise orbits and clocks coming in ASCII format (named 'RTNET' in this document) from a real-time GNSS engine. Each epoch begins with an asterisk character followed by the time as year, month, day of month, hour, minute and second. Subsequent records provide the following set of parameters for each satellite: 
+</p>
+<p>
+&lt;SatelliteID&gt; &lt;key&gt; &lt;numValues&gt; &lt;value1 value2 ...&gt; &lt;key&gt; &lt;numValues&gt; &lt;value1 value2 ...&gt; ...
 &nbsp;
 </p>
@@ -1980 +1979 @@
 <tr><td>Clk</td><td>Satellite clock correction in meters, relativistic correction applied like in broadcast clocks</td></tr>
 <tr><td>Vel</td><td>Satellite velocity in meters per second</td></tr>
-<tr><td>CoM</td><td>Satellite Centen of Mass coordinates in meters</td></tr>
+<tr><td>CoM</td><td>Satellite Center of Mass coordinates in meters</td></tr>
 </table>
 </p>
@@ -2020 +2019 @@
 </p>
 <p>
-Note that each end of an epoch in the incoming stream is indicated by an ASCII string 'EOE' (for End Of Epoch).
+Note that the end of an epoch in the incoming stream is indicated by an ASCII string 'EOE' (for End Of Epoch).
 </p>
 <p>
@@ -2775 +2774 @@
 <tr>
 <td>Mar 2013 &nbsp;</td><td>Version 2.9 &nbsp;</td>
-<td>[Add] Started work on new version in Mar 2013<br>[Bug] SSR stream upload buffering disabled<br>[Mod] Format for feeding a connected engine<br>[Mod] RTNET format for receiving data from a connected engine</td>
+<td>[Add] Started work on new version in Mar 2013<br>[Bug] SSR stream upload buffering disabled<br>[Mod] Format for feeding a connected GNSS engine<br>[Mod] RTNET format for receiving data from a connected GNSS engine</td>
 </tr>