Changeset 7853 in ntrip for trunk


Ignore:
Timestamp:
Apr 6, 2016, 9:00:34 AM (3 years ago)
Author:
weber
Message:

Documentation completed

File:
1 edited

Legend:

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

    r7847 r7853  
    546546</p>
    547547<p>
    548 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 precise orbits and clocks. 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.
     548The 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 precise orbits and clocks. 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.
    549549</p>
    550550<p><img src="IMG/screenshot10.png"/></p>
     
    806806
    807807<p>
    808 BNC comes with a number of configuration examples, which can be used on all operating systems. Copy the complete directory 'Example_Configs' which comes with the software to your disc. It includes sub-directories 'Input' and 'Output'. There are several ways to start BNC using one of the example configurations:
     808BNC comes with a number of configuration examples which can be used on all operating systems. Copy the complete directory 'Example_Configs' which comes with the software to your disc. It includes sub-directories 'Input' and 'Output'. There are several ways to start BNC using one of the example configurations:
    809809</p>
    810810<ul>
     
    10361036<li>Configuration File 'Empty.bnc'<br>
    10371037Purpose: Provide an empty example configuration file for
    1038 BNC, which only contains default settings.
     1038BNC which only contains default settings.
    10391039</li>
    10401040
     
    13171317</p>
    13181318<p>
    1319 It is important to understand that converting RTCM streams to RINEX files requires a priori information on observation types for specifying a complete RINEX header. Regarding the RINEX Version 2 file header, BNC simply introduces all observation types defined in the Version 2 standard and later reports "0.000" for observations, which are not received. However, following this approach is not possible for RINEX Version 3 files from RTCM Version 3 MSM streams because of the huge number of observation types, which might in principle show up. The solution implemented in BNC is to start with RINEX Version 3 observation type records from skeleton files (see section 'Skeleton Extension' and 'Skeleton Mandatory') and switch to a default selection of observation types when such file is not available or does not contain the required information. The following is the default selection of observation types specified for a RINEX Version 3 file:
     1319It is important to understand that converting RTCM streams to RINEX files requires a priori information on observation types for specifying a complete RINEX header. Regarding the RINEX Version 2 file header, BNC simply introduces all observation types defined in the Version 2 standard and later reports "0.000" for observations which are not received. However, following this approach is not possible for RINEX Version 3 files from RTCM Version 3 MSM streams because of the huge number of observation types, which might in principle show up. The solution implemented in BNC is to start with RINEX Version 3 observation type records from skeleton files (see section 'Skeleton Extension' and 'Skeleton Mandatory') and switch to a default selection of observation types when such file is not available or does not contain the required information. The following is the default selection of observation types specified for a RINEX Version 3 file:
    13201320</p>
    13211321<pre>
     
    16491649</p>
    16501650<p>
    1651 When specifying several input files, BNC will concatenate their contents. In case of RINEX Observation input files with different observation type header records, BNC will output only one set of adjusted observation type records in the RINEX header, which fits to the whole file content.
     1651When specifying several input files, BNC will concatenate their contents. In case of RINEX Observation input files with different observation type header records, BNC will output only one set of adjusted observation type records in the RINEX header which fits to the whole file content.
    16521652</p>
    16531653<p>
     
    22082208
    22092209<p>
    2210 While we have a plain ASCII standard for saving Broadcast Ephemeris in RINEX Navigation files, we do not have an equivalent standard for corrections to Broadcast Ephemeris. Hence, BNC saves Broadcast Correction files following its own format definition. The filename convention for Broadcast Correction files follows the convention for RINEX Version 2 files except for the last character of the filename suffix, which is set to 'C'.
     2210While we have a plain ASCII standard for saving Broadcast Ephemeris in RINEX Navigation files, we do not have an equivalent standard for corrections to Broadcast Ephemeris. Hence, BNC saves Broadcast Correction files following its own format definition. The filename convention for Broadcast Correction files follows the convention for RINEX Version 2 files except for the last character of the filename suffix which is set to 'C'.
    22112211</p>
    22122212
     
    26592659</p>
    26602660<p>
    2661 The following is an example for unsynchronized IP port output, which presents observations from GPS and GLONASS as collected through stream WTZR0. The format for synchronized and unsynchronized output of observations is very much the same. However, unsynchronized output does not have 'Epoch Records' and 'Observation Records'. Instead each record contains the 'GPS Week Number' and 'GPS Second of Week' time tag between the mountpoint string and the satellite number, see Table 2 for format details.
     2661The following is an example for unsynchronized IP port output which presents observations from GPS and GLONASS as collected through stream WTZR0. The format for synchronized and unsynchronized output of observations is very much the same. However, unsynchronized output does not have 'Epoch Records' and 'Observation Records'. Instead each record contains the 'GPS Week Number' and 'GPS Second of Week' time tag between the mountpoint string and the satellite number, see Table 2 for format details.
    26622662</p>
    26632663
     
    28412841<p><h4>2.12 <a name="misc">Miscellaneous</h4></p>
    28422842<p>
    2843 This section describes several miscellaneous options, which can be applied to a single stream (mountpoint) or to all configured streams.
     2843This section describes several miscellaneous options which can be applied to a single stream (mountpoint) or to all configured streams.
    28442844</p>
    28452845
     
    29092909
    29102910<p>
    2911 Please note further that RTCM Version 3 message types 1084 for GLONASS do not contain GLONASS channel numbers. Observations from these messages can only be decoded when you include 1020 GLONASS ephemeris messages to your stream, which contain the channels. You could also consider adding a second stream carrying 1087 GLONASS observation messages or 1020 GLONASS ephemeris messages as both contain the GLONASS channel numbers.
     2911Please note further that RTCM Version 3 message types 1084 for GLONASS do not contain GLONASS channel numbers. Observations from these messages can only be decoded when you include 1020 GLONASS ephemeris messages to your stream which contain the channels. You could also consider adding a second stream carrying 1087 GLONASS observation messages or 1020 GLONASS ephemeris messages as both contain the GLONASS channel numbers.
    29122912</p>
    29132913<p>
     
    35323532
    35333533<p>
    3534 As the convergence characteristic of a PPP solution can be influenced by the ratio of sigmas for code and phase, you may like to introduce sigmas, which differ from the default values.
     3534As the convergence characteristic of a PPP solution can be influenced by the ratio of sigmas for code and phase, you may like to introduce sigmas which differ from the default values.
    35353535<ul>
    35363536<li>Introducing a smaller sigma (higher accuracy) for code observations or a bigger sigma for phase observations leads to better results shortly after program start. However, it may take more time until you finally get the best possible solution.</li>
     
    37003700
    37013701<p>
    3702 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.
     3702With 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.
    37033703</p>
    37043704<p>
     
    38273827<tr><td>CoM</td><td>Satellite Center of Mass coordinates in meters</td></tr>
    38283828<tr><td>CodeBias</td><td>Satellite Code Biases in meters with two characters for frequency and tracking mode per bias as defined in RINEX 3 and preceded by total number of biases</td></tr>
    3829 <tr><td>YawAngle</td><td>Satellite Yaw Angle in radian, restricted to be in [0, 2&#960], which shall be used for the computation of phase wind-up correction</td></tr>
    3830 <tr><td>YawRate</td><td>Satellite Yaw Rate in radian per second, which is the rate of Yaw Angle</td></tr>
     3829<tr><td>YawAngle</td><td>Satellite Yaw Angle in radian, restricted to be in [0, 2&#960] which shall be used for the computation of phase wind-up correction</td></tr>
     3830<tr><td>YawRate</td><td>Satellite Yaw Rate in radian per second which is the rate of Yaw Angle</td></tr>
    38313831<tr><td>PhaseBias</td><td>Satellite Phase Biases in meters with two characters for frequency and tracking mode per bias as defined in RINEX 3, preceded by total number of biases and followed by Signal Wilde-Lane Integer Indicator as well as Signal Discontinuity Counter</td></tr>
    38323832</table>
     
    41384138<li>A 'SSR Provider ID' is issued by RTCM SC-104 on request to identify a SSR service (see e.g. <u>http://software.rtcm-ntrip.org/wiki/SSRProvider</u>). This ID is globally unique. Values vary in the range of 0-65535. Values in the range of 0-255 are reserved for experimental services.</li>
    41394139<li>A provider may generate several Broadcast Ephemeris correction streams with different contents. The 'SSR Solution ID' indicates different SSR services of one SSR provider. Values vary in the range of 0-15.</li>
    4140 <li>A change of the 'IOD SSR' is used to indicate a change in the SSR generating configuration, which may be relevant for the rover. Values vary in the range of 0-15.</li>
     4140<li>A change of the 'IOD SSR' is used to indicate a change in the SSR generating configuration which may be relevant for the rover. Values vary in the range of 0-15.</li>
    41414141</ul>
    41424142</p>
Note: See TracChangeset for help on using the changeset viewer.