Changeset 4203 in ntrip
- Timestamp:
- May 22, 2012, 9:20:10 AM (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/BNC/bnchelp.html
r4201 r4203 1414 1414 </p> 1415 1415 <p> 1416 Once XYZ coordinate components aredefined, the 'PPP' line in BNC's logfile is extended by Nort, East and Up displacements to (example):1416 Once a XYZ coordinate is defined, the 'PPP' line in BNC's logfile is extended by Nort, East and Up displacements to (example): 1417 1417 </p> 1418 1418 <pre> … … 1569 1569 <p><a name="pppquick"><h4>3.12.7.7 Quick-Start - optional if XYZ is set</h4></p> 1570 1570 <p> 1571 Enter the lenght of a startup period in seconds for which you want to fix the PPP solution to a known XYZ coordinate. Constraining coordinate components is done in BNC through setting the 'XYZ White Noise' temporarily to zero.1572 </p> 1573 <p> 1574 This so-called Quick-Start option allows the PPP solutions to rapidly converge after startup. It requires that the antenna remains unmoved on the know position throughout the defined period. A value of 120 (default) is likely to be an appropriate choice for 'Quick-Start'1575 <p> 1576 You may need to create your own reference coordinate through running BNC for an hour in normal mode before applying the Quick-Startoption. Don't forget to introduce a realistic sigma 'XYZ Ini' according to the coordinate's precision.1571 Enter the lenght of a startup period in seconds for which you want to fix the PPP solution to a known XYZ coordinate. Constraining coordinates is done in BNC through setting the 'XYZ White Noise' temporarily to zero. 1572 </p> 1573 <p> 1574 This so-called Quick-Start option allows the PPP solutions to rapidly converge after startup. It requires that the antenna remains unmoved on the know position throughout the defined period. A value of 60 is likely to be an appropriate choice for 'Quick-Start'. Default is an empty option field, meaning that you don't want BNC to start in 'Quick-Start' mode. 1575 <p> 1576 You may need to create your own reference coordinate through running BNC for an hour in normal mode before applying the 'Quick-Start' option. Don't forget to introduce a realistic sigma 'XYZ Ini' according to the coordinate's precision. 1577 1577 </p> 1578 1578 … … 1585 1585 <p><a name="pppgap"><h4>3.12.7.8 Maximal Solution Gap - optional if Quick-Start is set</h4></p> 1586 1586 <p> 1587 Specify a 'Maximum Solution Gap' in seconds. Should the time span between two consecutive solutions exceed this limit, the algorithm returns into the Quick-Start mode and fixes the introduced reference coordinate for the specified Quick-Start period. A value of '120' seconds could be an appropriate choice.1588 </p> 1589 <p> 1590 This option makes only sense for a stationary operated receiver where solution convergence can be enforced because a good approximation for the rover position is known. Default is an empty option field, meaning that you don't want BNC to return into the Quick-Startmode after failures caused i.e. by longer lasting outages.1587 Specify a 'Maximum Solution Gap' in seconds. Should the time span between two consecutive solutions exceed this limit, the algorithm returns into the 'Quick-Start' mode and fixes the introduced reference coordinate for the specified 'Quick-Start' period. A value of '60' seconds could be an appropriate choice. 1588 </p> 1589 <p> 1590 This option makes only sense for a stationary operated receiver where solution convergence can be enforced because a good approximation for the rover position is known. Default is an empty option field, meaning that you don't want BNC to return into the 'Quick-Start' mode after failures caused i.e. by longer lasting outages. 1591 1591 </p> 1592 1592 … … 1598 1598 <p><a name="pppsigc"><h4>3.12.8.1 Code - mandatory if 'Use Phase Obs' is set</h4></p> 1599 1599 <p> 1600 When 'Use phase obs' is set in BNC, the PPP solution will be carried out using both, code and phase observations. A sigma of 5.0 m for code observations and a sigma of 0.02 m for phase observations (defaults) are used to combine both types of observations. As the convergence characteristic of a PPP solution can be influenced by the ratio of the sigmas for code and phase, you may like to introduce you own sigmas for code and phase observations which differ from the default values.1601 <ul> 1602 <li>Introducing a smaller sigma (higher accuracy) for code observations or a larger sigma for phase observations leads to better results shortly after program start. However, it may take more time till you finally get the best possible solution s.</li>1600 When 'Use phase obs' is set in BNC, the PPP solution will be carried out using both, code and phase observations. A sigma of 10.0 m for code observations and a sigma of 0.02 m for phase observations (defaults) are used to combine both types of observations. As the convergence characteristic of a PPP solution can be influenced by the ratio of the sigmas for code and phase, you may like to introduce you own sigmas for code and phase observations which differ from the default values. 1601 <ul> 1602 <li>Introducing a smaller sigma (higher accuracy) for code observations or a larger sigma for phase observations leads to better results shortly after program start. However, it may take more time till you finally get the best possible solution.</li> 1603 1603 <li>Introducing a larger sigma (lower accuracy) for code observations or a smaller sigma for phase observations may lead to less accurate results shortly after program start and thus a prolonged period of convergence but could provide better positions in the long run.</li> 1604 1604 </ul> 1605 1605 </p> 1606 1606 <p> 1607 Specify a sigma for code observations. Default is 5.0 m.1607 Specify a sigma for code observations. Default is 10.0 m. 1608 1608 </p> 1609 1609 … … 1615 1615 <p><a name="pppsigxyzi"><h4>3.12.8.3 XYZ Init - mandatory</h4></p> 1616 1616 <p> 1617 Enter a sigma in meters for the initial XYZ coordinate components. A value of 100.0 (default) may be an appropriate choice. However, this value may be significantly smaller (i.e. 0.01) when starting for example from a station with known XZY position in Quick-Start mode.1617 Enter a sigma in meters for the initial XYZ coordinate. A value of 100.0 (default) may be an appropriate choice. However, this value may be significantly smaller (i.e. 0.01) when starting for example from a station with known XZY position in Quick-Start mode. 1618 1618 </p> 1619 1619 1620 1620 <p><a name="pppsigxyzn"><h4>3.12.8.4 XYZ White Noise - mandatory</h4></p> 1621 1621 <p> 1622 Enter a sigma in meters for the 'White Noise' of estimated XYZ coordinate components. A value of 100.0 (default) may be appropriate considering the potential movementof a rover.1622 Enter a sigma in meters for the 'White Noise' of estimated XYZ coordinate components. A value of 100.0 (default) may be appropriate when considering possible sudden movements of a rover. 1623 1623 </p> 1624 1624 … … 1635 1635 <p><a name="combi"><h4>3.13. Combine Corrections</h4></p> 1636 1636 <p> 1637 BNC allows to process several orbit and clock correction sstreams in real-time to produce, encode, upload and save a combination of Broadcast Corrections from various providers. It is so far only the satellite clock corrections which are combined while orbit corrections in the combination product as well as the product update rates are just taken over from one of the incoming Broadcast Correction streams. Combining only clock corrections using a fixed orbit reference has the possibility to introduce some analysis inconsistencies. We may therefore eventually consider improvements on this approach. The clock combination can be based either on a plain 'Single-Epoch' or on a 'Kalman' Filter approach.1637 BNC allows to process several orbit and clock correction streams in real-time to produce, encode, upload and save a combination of Broadcast Corrections from various providers. It is so far only the satellite clock corrections which are combined while orbit corrections in the combination product as well as the product update rates are just taken over from one of the incoming Broadcast Correction streams. Combining only clock corrections using a fixed orbit reference has the possibility to introduce some analysis inconsistencies. We may therefore eventually consider improvements on this approach. The clock combination can be based either on a plain 'Single-Epoch' or on a 'Kalman' Filter approach. 1638 1638 </p> 1639 1639 <p> … … 1647 1647 In view of IGS real-time products, the 'Combine Corrections' functionality has been integrated in BNC because 1648 1648 <ul> 1649 <li>the software with its Graphic User Interface and wide range of supported Operati onSystems represents a perfect platform to process many Broadcast Correction streams in parallel;</li>1649 <li>the software with its Graphic User Interface and wide range of supported Operating Systems represents a perfect platform to process many Broadcast Correction streams in parallel;</li> 1650 1650 <li>outages of single AC product streams can be mitigated through merging several incoming streams into a combined product;</li> 1651 1651 <li>generating a combination product from several AC products allows detecting and rejecting outliers;</li> … … 1653 1653 <li>an individual AC could prefer to disseminate a stream combined from primary and backup IT resources to reduce outages;</li> 1654 1654 <li>it enables a BNC PPP user to follow his own preference in combining streams from individual ACs for Precise Point Positioning;</li> 1655 <li>it allows an instantaneous quality control of the combination process not only in the time domain but also in the space domain; this can be done through direct application of the combination stream in a PPP solution even without prior stream upload to an NTRIP Broadcaster;</li> 1656 <li>it provides the means to output SP3 files containing precise orbit and clock information for further processing using other tools than BNC.</li> 1657 </ul> 1658 </p> 1659 <p> 1660 Note that the combination process requires real-time access to Broadcast Ephemeris. So, in addition to the orbit and clock corrections streams BNC must pull a stream carrying Broadcast Ephemeris in the form of RTCM Version 3 messages. Stream 'RTCM3EPH' on caster <u>products.igs-ip.net</u> is an example for that. 1655 <li>it allows an instantaneous quality control of the combination process not only in the time domain but also in the space domain; this can be done through direct application of the combined stream in a PPP solution even without prior upload to an NTRIP Broadcaster;</li> 1656 <li>it provides the means to output SP3 and Clock RINEX files containing precise orbit and clock information for further processing using other tools than BNC.</li> 1657 </ul> 1658 </p> 1659 <p> 1660 Note that the combination process requires real-time access to Broadcast Ephemeris. So, in addition to the orbit and clock correction streams BNC must pull a stream carrying Broadcast Ephemeris in the form of RTCM Version 3 messages. Stream 'RTCM3EPH' on caster <u>products.igs-ip.net</u> is an example for that. 1661 </p> 1662 <p> 1663 Note further that you need to tick the 'Use GLONASS' option which is part ot the 'PPP (2)' panel in case you want to produce an GPS plus GLONASS combination. 1661 1664 </p> 1662 1665 <p> … … 1664 1667 </p> 1665 1668 <p> 1666 Note further that you need to tick the 'Use GLONASS' option which is part ot the 'PPP (2)' panel in case you want to produce an GPS plus GLONASS combination. 1667 </p> 1668 <p> 1669 With respect to IGS, it is important to understand that a major effect in the combination of GNSS orbit and clock corrections 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. 1669 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. 1670 1670 </p> 1671 1671 <p> … … 1673 1673 </p> 1674 1674 <p> 1675 The following recursive algorithm is used to detect orbit outliers in the Kalman Filter combination when corrections are provided by several ACs:1675 The following recursive algorithm is used to detect orbit outliers in the Kalman Filter combination when Broadcast Corrections are provided by several ACs: 1676 1676 <br> 1677 1677 Step 1: We don't produce a combination for a certain satellite if only one AC provides corrections for it. … … 1683 1683 Step 4: We find the greatest difference between AC specific and mean satellite positions. 1684 1684 <br> 1685 Step 5: If that is less than 0.2 mthe conclusion is that we don't have an outlier and can proceed to the next epoch.1685 Step 5: If that is less than a threshold, the conclusion is that we don't have an outlier and can proceed to the next epoch. 1686 1686 <br> 1687 Step 6: If that is greater 0.2 mthen corrections of the affiliated AC are ignored for the affected epoch and the outlier detection restarts with step 1.1687 Step 6: If that is greater than a threshold, then corrections of the affiliated AC are ignored for the affected epoch and the outlier detection restarts with step 1. 1688 1688 </p> 1689 1689 <p> … … 1691 1691 </p> 1692 1692 <p> 1693 Note further that the combination procedure in BNC also - formally - works with only one Broadcast Corrections stream specified for combination. 1694 </p> 1695 <p> 1696 The part of BNC which enables the combination of orbit and clock corrections streams is not intended for publication under GNU General Public License (GPL). However, pre-compiled BNC binaries which support the 'Combine Corrections' option will be available for personal usage. 1693 The part of BNC which enables the combination of Broadcast Corrections is not intended for publication under GNU General Public License (GPL). However, pre-compiled BNC binaries which support the 'Combine Corrections' option are made available. 1697 1694 </p> 1698 1695 … … 1702 1699 </p> 1703 1700 <p> 1704 Note that an appropriate 'Wait for full corr epoch' value needs to be specified for the combination under the 'Broadcast Corrections' tab. To give an example: a value of '15'sec would make sense if the update rate of incoming clock corrections is 10 sec.1705 </p> 1706 <p> 1707 The sequence of entries in the 'Combine Corrections Table'is not of importance. Note that the orbit information in the final combination stream is just copied from one of the incoming streams. The stream used for providing the orbits may vary over time: if the orbit providing stream has an outage then BNC switches to the next remaining stream for getting hold of the orbit information.</p>1708 <p> 1709 Default is an empty 'Combine Corrections Table' meaning that you don't want BNC to combine orbit and clock correctionsstreams.1710 </p> 1711 <p> 1712 It is possible to specify only one Broadcast Ephemeris corrections stream in the 'Combine Corrections Table'. Instead of combining corrections from several sources BNC will then merge the single corrections stream with Broadcast Ephemeris to save results in SP3 and/or Clock RINEX format when specified accordingly under the 'Upload Corrections' tab.1701 Note that an appropriate 'Wait for full corr epoch' value needs to be specified for the combination under the 'Broadcast Corrections' tab. To give an example: a value of 15 sec would make sense if the update rate of incoming clock corrections is 10 sec. 1702 </p> 1703 <p> 1704 The sequence of entries in the 'Combine Corrections' table is not of importance. Note that the orbit information in the final combination stream is just copied from one of the incoming streams. The stream used for providing the orbits may vary over time: if the orbit providing stream has an outage then BNC switches to the next remaining stream for getting hold of the orbit information.</p> 1705 <p> 1706 Default is an empty 'Combine Corrections' table meaning that you don't want BNC to combine orbit and clock correction streams. 1707 </p> 1708 <p> 1709 It is possible to specify only one Broadcast Ephemeris corrections stream in the 'Combine Corrections' table. Instead of combining corrections from several sources BNC will then merge the single corrections stream with Broadcast Ephemeris to save results in SP3 and/or Clock RINEX format when specified accordingly under the 'Upload Corrections' tab. 1713 1710 </p> 1714 1711 1715 1712 <p><a name="combiadd"><h4>3.13.1.1 Add Row, Delete - optional</h4></p> 1716 1713 <p> 1717 Hit 'Add Row' button to add another row to the 'Combine Corrections Table'or hit the 'Delete' button to delete the highlighted row(s).1718 </p> 1719 1720 <p> 1721 The following screenshots describe an example setup of BNC when combining Broadcast Correction streams and upload them to an NTRIP Broadcaster. Note that it requires specifying options under tabs 'Combine Corrections' and 'Upload Corrections'. The example uses the combination product to simultaneously carry out an 'INTERNAL' PPP solution in Quickstartmode which allows monitoring the quality of the combination product in the space domain.1714 Hit 'Add Row' button to add another row to the 'Combine Corrections' table or hit the 'Delete' button to delete the highlighted row(s). 1715 </p> 1716 1717 <p> 1718 The following screenshots describe an example setup of BNC when combining Broadcast Correction streams and uploading them to an NTRIP Broadcaster. Note that it requires specifying options under tabs 'Combine Corrections' and 'Upload Corrections'. The example uses the combination product to simultaneously carry out an 'INTERNAL' PPP solution in 'Quick-Start' mode which allows monitoring the quality of the combination product in the space domain. 1722 1719 </p> 1723 1720 … … 1732 1729 <p><u>Figure 17:</u> 'INTERNAL' PPP with BNC using combined Broadcast Corrections stream.</p> 1733 1730 1734 <p><a name="combimethod"><h4>3.13.1.2 Method - mandatory if 'Combine Corrections Table'is populated</h4></p>1735 <p> 1736 Select a clock combination method. Available options are Kalman 'Filter' and 'Single-Epoch. It is suggested to use the Kalman Filter approach in case the combined stream of Broadcast Corrections is intended for Precise Point Positioning support.1737 </p> 1738 1739 <p><a name="combimax"><h4>3.13.1.3 Maximal Residuum - mandatory if 'Combine Corrections Table'is populated</h4></p>1731 <p><a name="combimethod"><h4>3.13.1.2 Method - mandatory if 'Combine Corrections' table is populated</h4></p> 1732 <p> 1733 Select a clock combination method. Available options are Kalman 'Filter' and 'Single-Epoch. It is suggested to use the Kalman Filter approach in case the combined stream of Broadcast Corrections is intended for Precise Point Positioning. 1734 </p> 1735 1736 <p><a name="combimax"><h4>3.13.1.3 Maximal Residuum - mandatory if 'Combine Corrections' table is populated</h4></p> 1740 1737 1741 1738 <p>BNC combines all incoming clocks according to specified weights. Individual clock estimates that differ by more than 'Maximal Residuum' meters from the average of all clocks will be ignored.<p> … … 1743 1740 <p>Default is a 'Maximal Residuum' of 999.0 meters</p> 1744 1741 1745 <p><a name="combismpl"><h4>3.13.1.4 Sampling - mandatory if 'Combine Corrections Table'is populated</h4></p>1742 <p><a name="combismpl"><h4>3.13.1.4 Sampling - mandatory if 'Combine Corrections' table is populated</h4></p> 1746 1743 <p>Specify a combination sampling interval. Clock and orbit corrections will be produced following that interval. A value of 10 sec may be an appropriate choice.</p> 1747 1744 … … 1753 1750 either generated by BNC as a combination of several individual Broadcast Correction streams coming from an number of real-time Analysis Centers (ACs), see section 'Combine Corrections',</li> 1754 1751 <li> 1755 or generated by BNC because the program receives an ASCII stream of precise satellite orbits and clocks via IP port from a connected real-time GNSS engine. Such a stream would be expected in a plain ASCII format and the associated 'decoder' string would have to be 'RTNET'. </li>1752 or generated by BNC while the program receives an ASCII stream of precise satellite orbits and clocks via IP port from a connected real-time GNSS engine. Such a stream would be expected in a plain ASCII format and the associated 'decoder' string would have to be 'RTNET', see format description below. </li> 1756 1753 </ol> 1757 1754 The procedure taken by BNC to generate the clock and orbit corrections to Broadcast Ephemeris and upload them to an NTRIP Broadcaster is as follow: 1758 1755 <ul> 1759 <li>Continuously receive up-to-date Broadcast Ephemeris carrying approximate orbits and clocks for all satellites. Read new Broadcast Ephemeris immediately whenever they become available. This information may come via a stream of RTCM messages generated from a BNC instance.</li>1756 <li>Continuously receive up-to-date Broadcast Ephemeris carrying approximate orbits and clocks for all satellites. Read new Broadcast Ephemeris immediately whenever they become available. This information may come via a stream of RTCM messages generated from another BNC instance.</li> 1760 1757 </ul> 1761 1758 Then, epoch by epoch: … … 1765 1762 <li>Calculate differences dX,dY,dZ between Broadcast Ephemeris and IGS08 orbits. </li> 1766 1763 <li>Transform these differences into radial, along-track and cross-track corrections to Broadcast Ephemeris orbits. </li> 1767 <li>Calculate corrections to Broadcast Ephemeris clocks as differences between Broadcast Ephemeris and IGS08 clocks. </li>1764 <li>Calculate corrections to Broadcast Ephemeris clocks as differences between Broadcast Ephemeris clocks and IGS08 clocks. </li> 1768 1765 <li>Encode Broadcast Ephemeris clock and orbit corrections in RTCM Version 3 format. </li> 1769 <li>Upload corrections stream to NTRIP Broadcaster. </li>1766 <li>Upload Broadcast Corrections stream to NTRIP Broadcaster. </li> 1770 1767 </ul> 1771 1768 <p> … … 2014 2011 </p> 2015 2012 <p> 2016 In case the 'Combine Corrections Table'contains only one Broadcast Corrections stream, BNC will merge that stream with Broadcast Ephemeris to save results in files specified here through SP3 and/or Clock RINEX file path. In such a case you have to define only the SP3 and Clock RINEX file path and no further options in the 'Upload Corrections' table.2013 In case the 'Combine Corrections' table contains only one Broadcast Corrections stream, BNC will merge that stream with Broadcast Ephemeris to save results in files specified here through SP3 and/or Clock RINEX file path. In such a case you have to define only the SP3 and Clock RINEX file path and no further options in the 'Upload Corrections' table. 2017 2014 </p> 2018 2015 … … 2767 2764 <br> 2768 2765 <li>File 'QuickStartPPP.bnc'<br> 2769 The purpose of this configuration is Precise Point Positioning in Quick Start mode from observations of a static receiver with precisely known position. The configuration reads RTCM Version 3 observations, orbit and clock correctors and a Broadcast Ephemeris stream. Positions are saved in NMEA format on disc and output through IP port for real-time visualization with tools like RTKNAVI.2766 The purpose of this configuration is Precise Point Positioning in Quick-Start mode from observations of a static receiver with precisely known position. The configuration reads RTCM Version 3 observations, orbit and clock correctors and a Broadcast Ephemeris stream. Positions are saved in NMEA format on disc and output through IP port for real-time visualization with tools like RTKNAVI. 2770 2767 </li> 2771 2768 <br> 2772 2769 <li>File 'PPPPostProc.bnc<br> 2773 The purpose of this configuration is Precise Point Positioning in Post Processing mode. BNC reads a RINEX Observation and a RINEX Version 3 Navigation files and a Broadcast Corrections files. PPP processing otions are set in support of the Quick Start mode. The output is saved in a specific Post Processing logfile and contains the coordinates derived over time following the implemented PPP filter algorithm.2770 The purpose of this configuration is Precise Point Positioning in Post Processing mode. BNC reads a RINEX Observation and a RINEX Version 3 Navigation files and a Broadcast Corrections files. PPP processing otions are set in support of the Quick-Start mode. The output is saved in a specific Post Processing logfile and contains the coordinates derived over time following the implemented PPP filter algorithm. 2774 2771 </li> 2775 2772 <br>
Note:
See TracChangeset
for help on using the changeset viewer.