- Timestamp:
- Apr 6, 2016, 9:00:34 AM (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/BNC/src/bnchelp.html
r7847 r7853 546 546 </p> 547 547 <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.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. 549 549 </p> 550 550 <p><img src="IMG/screenshot10.png"/></p> … … 806 806 807 807 <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: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: 809 809 </p> 810 810 <ul> … … 1036 1036 <li>Configuration File 'Empty.bnc'<br> 1037 1037 Purpose: Provide an empty example configuration file for 1038 BNC ,which only contains default settings.1038 BNC which only contains default settings. 1039 1039 </li> 1040 1040 … … 1317 1317 </p> 1318 1318 <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: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: 1320 1320 </p> 1321 1321 <pre> … … 1649 1649 </p> 1650 1650 <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.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. 1652 1652 </p> 1653 1653 <p> … … 2208 2208 2209 2209 <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'.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'. 2211 2211 </p> 2212 2212 … … 2659 2659 </p> 2660 2660 <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.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. 2662 2662 </p> 2663 2663 … … 2841 2841 <p><h4>2.12 <a name="misc">Miscellaneous</h4></p> 2842 2842 <p> 2843 This section describes several miscellaneous options ,which can be applied to a single stream (mountpoint) or to all configured streams.2843 This section describes several miscellaneous options which can be applied to a single stream (mountpoint) or to all configured streams. 2844 2844 </p> 2845 2845 … … 2909 2909 2910 2910 <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.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. 2912 2912 </p> 2913 2913 <p> … … 3532 3532 3533 3533 <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.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. 3535 3535 <ul> 3536 3536 <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> … … 3700 3700 3701 3701 <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.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. 3703 3703 </p> 3704 3704 <p> … … 3827 3827 <tr><td>CoM</td><td>Satellite Center of Mass coordinates in meters</td></tr> 3828 3828 <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π] ,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π] 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> 3831 3831 <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> 3832 3832 </table> … … 4138 4138 <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> 4139 4139 <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> 4141 4141 </ul> 4142 4142 </p>
Note:
See TracChangeset
for help on using the changeset viewer.