Changeset 4996 in ntrip


Ignore:
Timestamp:
Mar 24, 2013, 9:22:18 PM (9 years ago)
Author:
weber
Message:

Documentation completed

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/BNC/src/bnchelp.html

    r4995 r4996  
    11151115</p>
    11161116<p>
    1117 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.
    1118 </p>
    1119 
    1120 <p>Note on 'SlipCount':<br>
    1121 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.
     1117Any 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.
     1118</p>
     1119
     1120<p>Note on 'Slip Count':<br>
     1121It 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.
    11221122</p>
    11231123
     
    19621962</p>
    19631963<p>
    1964 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.
    1965 </p>
    1966 
    1967 <p>
    1968 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:
    1969 <p>
    1970 <p>
    1971 &lt;SatelliteID&gt; &lt;key&gt; &lt;numValues&gt; &lt;value1 value2 ...&gt; &lt;key&gt; &lt;numValues&gt; &lt;value1 value2 ...&gt; ... weber
     1964BNC 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.
     1965</p>
     1966<p>
     1967Below 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:
     1968</p>
     1969<p>
     1970&lt;SatelliteID&gt; &lt;key&gt; &lt;numValues&gt; &lt;value1 value2 ...&gt; &lt;key&gt; &lt;numValues&gt; &lt;value1 value2 ...&gt; ...
    19721971&nbsp;
    19731972</p>
     
    19801979<tr><td>Clk</td><td>Satellite clock correction in meters, relativistic correction applied like in broadcast clocks</td></tr>
    19811980<tr><td>Vel</td><td>Satellite velocity in meters per second</td></tr>
    1982 <tr><td>CoM</td><td>Satellite Centen of Mass coordinates in meters</td></tr>
     1981<tr><td>CoM</td><td>Satellite Center of Mass coordinates in meters</td></tr>
    19831982</table>
    19841983</p>
     
    20202019</p>
    20212020<p>
    2022 Note that each end of an epoch in the incoming stream is indicated by an ASCII string 'EOE' (for End Of Epoch).
     2021Note that the end of an epoch in the incoming stream is indicated by an ASCII string 'EOE' (for End Of Epoch).
    20232022</p>
    20242023<p>
     
    27752774<tr>
    27762775<td>Mar 2013 &nbsp;</td><td>Version 2.9 &nbsp;</td>
    2777 <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>
     2776<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>
    27782777</tr>
    27792778
Note: See TracChangeset for help on using the changeset viewer.