Changeset 7710 in ntrip for trunk


Ignore:
Timestamp:
Jan 25, 2016, 12:43:49 PM (4 years ago)
Author:
weber
Message:

Documentation completed

File:
1 edited

Legend:

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

    r7709 r7710  
    243243<tr><td>17</td><td>Example for pulling, saving and output of Broadcast Corrections using BNC</td><td>2.8.3</td></tr>
    244244<tr><td>18</td><td>Synchronized BNC output via IP port to feed a GNSS real-time engine</td><td>2.9</td></tr>
    245 <tr><td>19</td><td>Flowcharts, BNC forwarding a stream to a serial connected receiver; sending NMEA sentences is mandatory for VRS streams</td><td>2.10</td></tr>
    246 <tr><td>20</td><td>BNC pulling a VRS stream to feed a serial connected RTK rover</td><td>2.10</td></tr>
     245<tr><td>19</td><td>Flowcharts, BNC forwarding a stream to a serially connected receiver; sending NMEA sentences is mandatory for VRS streams</td><td>2.10</td></tr>
     246<tr><td>20</td><td>BNC pulling a VRS stream to feed a serially connected RTK rover</td><td>2.10</td></tr>
    247247<tr><td>21</td><td>RTCM message numbers, latencies and observation types logged by BNC</td><td>2.12</td></tr>
    248248<tr><td>22</td><td>Real-time Precise Point Positioning with BNC, PPP Panel 1</td><td>2.13.1</td></tr>
     
    364364
    365365<p>
    366 Promoting Open RTCM Standards for streaming GNSS data over the Internet has been a major aspect in developing BNC as Open Source real-time software. Basically, the tool enables the test, validation and further evolution of new RTCM messages for precise satellite navigation. With high-level source code at hand, it also allows university education to catch up with comprehensive state-of-the-art positioning and potentially contribute fresh ideas which are free from any licensing.
     366Promoting Open RTCM Standards for streaming GNSS data over the Internet has been a major aspect in developing BNC as Open Source real-time software. Basically, the tool enables the test, validation and further evolution of new RTCM messages for precise satellite navigation. With high-level source code at hand, it also allows university education to catch up with comprehensive state-of-the-art positioning and potentially contributes fresh ideas which are free from any licensing.
    367367</p>
    368368
     
    435435
    436436<p>
    437 Note that BNC allows to by-pass decoding and conversion algorithms for incoming streams, leave whatever is received untouched to save it in files or output it through local TCP/IP port.
     437Note that BNC allows to by-pass decoding and conversion algorithms for incoming streams, leaves whatever is received untouched to save it in files or output it through local TCP/IP port.
    438438</p>
    439439
    440440<p><h4>1.2 <a name="introSystem">Supported GNSS</h4></p>
    441441<p>
    442 BNC is permanently completed to finally support all existing GNSS systems throughout all features of the program. The table below shows in detail which GNSS systems are so far supported by particular applications when using the latest BNC version. Application areas named here are:
     442BNC is permanently completed to finally support all existing GNSS systems throughout all features of the program. The table below shows in detail which GNSS systems are supported so far by particular applications when using the latest BNC version. Application areas named here are:
    443443<ul>
    444444<li>Decoding of RTCM or RTNET streams</li>
     
    449449<li>Combining/merging SSR or ephemeris messages from various real-time sources</li>
    450450</ul>
    451 The table mentions if a message implementation in BNC could so far only be based on a 'RTCM Proposal'.
     451The table indicates if a message implementation in BNC could so far only be based on a 'RTCM Proposal'.
    452452</p>
    453453<p><u>Table 1:</u> Status of RTCM Version 3 message implementations in BNC supporting various GNSS systems</p>
     
    538538</p>
    539539<p>
    540 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.
     540The 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.
    541541</p>
    542542<p><img src="IMG/screenshot10.png"/></p>
     
    608608
    609609<p>
    610 <u>Linux Build:</u> Static library and shared library builds for BNC are provided for a selection of Linux distributions. Download the ZIP archive for a version which fits to your Linux system, unzip the archive and run the included BNC binary. A static build would be sufficient in case you <u>don't want</u> BNC to plot PPP results with Google Map (GM) or OpenStreetMap (OSM) maps in the background. GM/OSM usage requires BNC builds from shared libraries.
     610<u>Linux Build:</u> Static library and shared library builds for BNC are provided for a selection of Linux distributions. Download the ZIP archive for a version which fits to your Linux system, unzip the archive and run the included BNC binary. A static build would be sufficient in case you <u>do not want</u> BNC to plot PPP results with Google Map (GM) or OpenStreetMap (OSM) maps in the background. GM/OSM usage requires BNC builds from shared libraries.
    611611</p>
    612612
     
    625625
    626626<p><b>Static versus Shared Libraries</b><br>
    627 You can produce static or shared builds of BNC. <u>Static</u> builds are sufficient in case you don't want BNC to produce track maps on top of Google Map (GM) or OpenStreetMap (OSM). GM/OSM usage would require the QtWebKit library which can only be part of BNC builds from <u>shared</u> Qt libraries. Hence, having a shared library Qt installation available is a precondition for producing a shared library build of BNC.
     627You can produce static or shared builds of BNC. <u>Static</u> builds are sufficient in case you do not want BNC to produce track maps on top of Google Map (GM) or OpenStreetMap (OSM). GM/OSM usage would require the QtWebKit library which can only be part of BNC builds from <u>shared</u> Qt libraries. Hence, having a shared library Qt installation available is a precondition for producing a shared library build of BNC.
    628628</p>
    629629
     
    706706
    707707<p>
    708 Qt will be installed into directory /usr/local/Trolltech/Qt-4.8.5. To reconfigure, run 'gmake confclean' and 'configure'. Note that the '-prefix' option allows you to specify a directory for saving the Qt libraries. This ensures that you don't run into conflicts with other
     708Qt will be installed into directory /usr/local/Trolltech/Qt-4.8.5. To reconfigure, run 'gmake confclean' and 'configure'. Note that the '-prefix' option allows you to specify a directory for saving the Qt libraries. This ensures that you do not run into conflicts with other
    709709Qt installations on your host. Note further that the following two lines<pre>
    710710  export QTDIR="/usr/local/Trolltech/Qt-4.8.5"
     
    794794
    795795<p>
    796 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:
     796BNC 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:
    797797</p>
    798798<ul>
    799799<li>
    800 On graphical systems (except for Mac systems) you may use the computer mouse to 'drag' a configuration file icon and 'drop' it on top of BNC's program icon.
     800On graphical systems (except for Mac systems), you may use the computer mouse to 'drag' a configuration file icon and 'drop' it on top of BNC's program icon.
    801801</li>
    802802<li>
     
    831831
    832832<p>
    833 Note that the account for an Ntrip Broadcaster is usually limited to pulling a specified maximum number of streams at the same time. As running some of the example configurations requires pulling several streams, it is suggested to make sure that you don't exceed your account's limits.
     833Note that the account for an Ntrip Broadcaster is usually limited to pulling a specified maximum number of streams at the same time. As running some of the example configurations requires pulling several streams, it is suggested to make sure that you do not exceed your account's limits.
    834834</p>
    835835
     
    892892
    893893<li>File 'RTK.bnc'<br>
    894 Purpose: Feed a serial connected receiver with
     894Purpose: Feed a serially connected receiver with
    895895observations from a nearby reference station for conventional RTK. The stream is
    896896scanned for RTCM messages. Message type numbers and latencies of incoming
     
    10011001<li>File 'CombiPPP.bnc'<br>
    10021002Purpose: This configuration equals the 'Combi.bnc' configuration. However, the combined
    1003 Broadcast Corrections are in addition used for an 'INTERNAL' PPP solutions
     1003Broadcast Corrections are in addition used for an 'INTERNAL' PPP solution
    10041004based on observations from a static reference station with known precise
    10051005coordinates. This allows a continuous quality check of the combination product
     
    10231023<li>File 'Empty.bnc'<br>
    10241024Purpose: Provide an empty example configuration file for
    1025 BNC which only contains default settings.
     1025BNC, which only contains default settings.
    10261026</li>
    10271027
     
    10611061</p>
    10621062<p>
    1063 To cope with an increasing number of transmitting GNSS reference stations, the Federal Agency for Cartography and Geodesy (BKG) together with the Informatik Centrum Dortmund (ICD) in Germany developed a streaming protocol for satellite navigation data called 'Networked Transport of RTCM via Internet Protocol' (Ntrip). The protocol was built on top of the HTTP standard and included the provision of meta data describing the stream content. Any stream could now be globally transmitted over just one IP port: HTTP port 80. Stream availability and content details became part of the transport protocol. The concept was first published in 2003 (Weber and Honkala 2004, Weber et al. 2005a) and was based on three software components, namely an NtripServer pushing data from a reference station to an NtripCaster and an NtripClient pulling data from the stream splitting caster to support a rover receiver. (Note that from a socket-programmers perspective NtripServer and NtripClient both act as clients; only the NtripCaster operates as socket-server.) Ntrip could essentially benefit from Internet Radio developments. It was the ICECAST multimedia server which provided the bases for BKG's 'Professional Ntrip Broadcaster' with software published first in 2003 and of course again as Open Source under GPL.
     1063To cope with an increasing number of transmitting GNSS reference stations, the Federal Agency for Cartography and Geodesy (BKG) together with the Informatik Centrum Dortmund (ICD) in Germany developed a streaming protocol for satellite navigation data called 'Networked Transport of RTCM via Internet Protocol' (Ntrip). The protocol was built on top of the HTTP standard and included the provision of meta data describing the stream content. Any stream could now be globally transmitted over just one IP port: HTTP port 80. Stream availability and content details became part of the transport protocol. The concept was first published in 2003 (Weber and Honkala 2004, Weber et al. 2005a) and was based on three software components, namely an NtripServer pushing data from a reference station to an NtripCaster and an NtripClient pulling data from the stream splitting caster to support a rover receiver. (Note that from a socket-programmers perspective NtripServer and NtripClient both act as clients; only the NtripCaster operates as socket-server.) Ntrip could essentially benefit from Internet Radio developments. It was the ICECAST multimedia server, which provided the bases for BKG's 'Professional Ntrip Broadcaster' with software published first in 2003 and of course again as Open Source under GPL.
    10641064</p>
    10651065<p>
     
    10671067</p>
    10681068<p>
    1069 With the advent of Ntrip as an open streaming standard, BKG's interest turned towards taking advantage from free real-time access to GNSS observations. International Associations such as the IAG Reference Frame Sub Commissions for Africa (AFREF), Asia & Pacific (APREF), Europe (EUREF), North America (NAREF) Latin America & Caribbean (SIRGAS), and the International GNSS Service (IGS) maintain continental or even global GNSS networks with the majority of modern receivers supporting Ntrip stream upload. Through operating BKG's NtripCaster software, these networks became extremely valuable sources of real-time GNSS information.  In 2005, this was the starting point for developing the 'BKG Ntrip Client' (BNC) as a multi-stream Open Source NtripClient which allows pulling hundreds of streams simultaneously from any number of NtripCaster installations world-wide. Decoding incoming RTCM streams and output observations epoch by epoch via IP port to feed a real-time GNSS network engine became BNC's first and foremost ability (Weber and Mervart 2009). Converting decoded streams to short high-rate RINEX files to assist near real-time applications became a welcome by-product right from the start of this development.
    1070 </p>
    1071 <p>
    1072 Adding real-time Precise Point Positioning (PPP) support to BNC began in 2010 as an important completion in view of developing an Open RTCM Standard for that. According to the State Space Representation (SSR) model, new Version 3 messages are proposed to provide e.g. satellite orbit and clock corrections and ionospheric corrections as well as biases for code and phase data. The ultimate goal for SSR standardization is to reach centimeter level accuracy within seconds as an alternative to Network RTK methods such as VRS, FKP, and MAC. Because of interoperability aspects, an Open Standard in this area is of particular interest for clients. Regarding stand-alone PPP in BNC, it is worth mentioning that the program is not and can never be in competition with a receiver manufacturer's proprietary solution. Only software or services which are part of a receiver firmware could have the potential of becoming a thread for commercial interests. However, implementing or not implementing an Open PPP approach in a firmware is and will always remain a manufacturer's decision.
     1069With the advent of Ntrip as an open streaming standard, BKG's interest turned towards taking advantage from free real-time access to GNSS observations. International Associations such as the IAG Reference Frame Sub Commissions for Africa (AFREF), Asia & Pacific (APREF), Europe (EUREF), North America (NAREF) Latin America & Caribbean (SIRGAS), and the International GNSS Service (IGS) maintain continental or even global GNSS networks with the majority of modern receivers supporting Ntrip stream upload. Through operating BKG's NtripCaster software, these networks became extremely valuable sources of real-time GNSS information.  In 2005, this was the starting point for developing the 'BKG Ntrip Client' (BNC) as a multi-stream Open Source NtripClient that allows pulling hundreds of streams simultaneously from any number of NtripCaster installations world-wide. Decoding incoming RTCM streams and output observations epoch by epoch via IP port to feed a real-time GNSS network engine became BNC's first and foremost ability (Weber and Mervart 2009). Converting decoded streams to short high-rate RINEX files to assist near real-time applications became a welcome by-product right from the start of this development.
     1070</p>
     1071<p>
     1072Adding real-time Precise Point Positioning (PPP) support to BNC began in 2010 as an important completion in view of developing an Open RTCM Standard for that. According to the State Space Representation (SSR) model, new Version 3 messages are proposed to provide e.g. satellite orbit and clock corrections and ionospheric corrections as well as biases for code and phase data. The ultimate goal for SSR standardization is to reach centimeter level accuracy within seconds as an alternative to Network RTK methods such as VRS, FKP, and MAC. Because of interoperability aspects, an Open Standard in this area is of particular interest for clients. Regarding stand-alone PPP in BNC, it is worth mentioning that the program is not and can never be in competition with a receiver manufacturer's proprietary solution. Only software or services that are part of a receiver firmware could have the potential of becoming a thread for commercial interests. However, implementing or not implementing an Open PPP approach in a firmware is and will always remain a manufacturer's decision.
    10731073</p>
    10741074<p>
     
    11351135<p><h4>2.2.1 <a name="proxy">Proxy - Usage in a protected LAN</h4></p>
    11361136<p>
    1137 If you are running BNC within a protected Local Area Network (LAN), you might need to use a proxy server to access the Internet. Enter your proxy server IP and port number in case one is operated in front of BNC. If you don't know the IP and port of your proxy server, check the proxy server settings in your Internet browser or ask your network administrator.</p>
     1137If you are running BNC within a protected Local Area Network (LAN), you might need to use a proxy server to access the Internet. Enter your proxy server IP and port number in case one is operated in front of BNC. If you do not know the IP and port of your proxy server, check the proxy server settings in your Internet browser or ask your network administrator.</p>
    11381138<p>
    11391139Note that IP streaming is often not allowed in a LAN. In this case you need to ask your network administrator for an appropriate modification of the local security policy or for the installation of a TCP relay to the Ntrip Broadcasters. If this is not possible, you might need to run BNC outside your LAN on a host that has unobstructed connection to the Internet.
     
    11541154   No certificates could be verified
    11551155</pre>
    1156 Tick 'Ignore SSL authorization errors' if you generally trust the server and don't want to be bothered with this. Note that SSL communication is usually done over port 443.
     1156Tick 'Ignore SSL authorization errors' if you generally trust the server and do not want to be bothered with this. Note that SSL communication is usually done over port 443.
    11571157</p>
    11581158
     
    11671167<p><h4>2.3.1 <a name="genlog">Logfile - optional</h4></p>
    11681168<p>
    1169 Records of BNC's activities are shown in the 'Log' tab on the bottom of the main window. These logs can be saved into a file when a valid path is specified in the 'Logfile (full path)' field. The logfile name will automatically be extended by a string '_YYMMDD' for the current date. This leads to series of daily logfiles when running BNC continuously for extended. Message logs cover the communication status between BNC and the Ntrip Broadcaster as well as problems that may occur in the communication link, stream availability, stream delay, stream conversion etc. All times are given in UTC. The default value for 'Logfile (full path)' is an empty option field, meaning that BNC logs will not be saved into a file.
     1169Records of BNC's activities are shown in the 'Log' tab on the bottom of the main window. These logs can be saved into a file when a valid path is specified in the 'Logfile (full path)' field. The logfile name will automatically be extended by a string '_YYMMDD' for the current date. This leads to series of daily logfiles when running BNC continuously. Message logs cover the communication status between BNC and the Ntrip Broadcaster as well as problems that may occur in the communication link, stream availability, stream delay, stream conversion etc. All times are given in UTC. The default value for 'Logfile (full path)' is an empty option field, meaning that BNC logs will not be saved into a file.
    11701170</p>
    11711171<p>
     
    12001200<p><h4>2.3.3 <a name="genconf">Reread Configuration - optional</h4></p>
    12011201<p>
    1202 When operating BNC online in 'no window' mode (command line option -nw), some configuration options can nevertheless be changed on-the-fly without interrupting the running process. For that you force the program to reread parts of its configuration in pre-defined intervals from the disk. Select '1 min', '1 hour', or '1 day' to let BNC reread on-the-fly changeable configuration options every full minute, hour, or day. This lets in between edited options become effective without interrupting uninvolved threads.
     1202When operating BNC online in 'no window' mode (command line option -nw), some configuration options can nevertheless be changed on-the-fly without interrupting the running process. For that, you force the program to reread parts of its configuration in pre-defined intervals from the disk. Select '1 min', '1 hour', or '1 day' to let BNC reread on-the-fly changeable configuration options every full minute, hour, or day. This lets in-between edited options become effective without interrupting uninvolved threads.
    12031203</p>
    12041204
     
    12471247</p>
    12481248<p>
    1249 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:
     1249It 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:
    12501250</p>
    12511251<pre>
     
    12591259
    12601260<p>
    1261 Please note that RTCM Version 3 messages 1084 for GLONASS observations don't contain the channel numbers. However, these messages can only be converted to RINEX when you add messages which include the channel numbers. This could be done by means of an additional stream carrying 1087 GLONASS observation messages or an additional stream carrying 1020 GLONASS ephemeris messages. You could also consider setting up a streams which contains both, the 1084 and the 1020 messages.
     1261Please note that RTCM Version 3 messages 1084 for GLONASS observations do not contain the channel numbers. However, these messages can only be converted to RINEX when you add messages which include the channel numbers. This could be done by means of an additional stream carrying 1087 GLONASS observation messages or an additional stream carrying 1020 GLONASS ephemeris messages. You could also consider setting up a stream which contains both, the 1084 and the 1020 messages.
    12621262</p>
    12631263<p>
     
    13431343<p><h4>2.4.5 <a name="rnxskl">Skeleton Extension - optional</h4></p>
    13441344<p>
    1345 Whenever BNC starts to generate RINEX Observation files (and then once every day at midnight), it first tries to retrieve information needed for RINEX headers from so-called public RINEX header skeleton files which are derived from sitelogs. A HTTP or HTTPS link to a directory containing these skeleton files may be available through data field number 7 of the affected NET record in the source-table. See <u>http://www.epncb.oma.be:80/stations/log/skl/brus.skl</u> for an example of a public RINEX header skeleton file for EPN station Brussels. Note that the download of RINEX skeleton files from HTTPS websites requires the exchange of client and/or server certificates. Clarify 'SSL' options offered through panel 'Network' for details.
    1346 </p>
    1347 <p>
    1348 Sometimes public RINEX header skeleton files are not available, their content is not up to date, or you need to put additional/optional records in the RINEX header. For that BNC allows using personal skeleton files that contain the header records you would like to include. You can derive a personal RINEX header skeleton file from the information given in an up to date sitelog. A file in the RINEX Observations 'Directory' with a 'Skeleton extension' suffix is interpreted by BNC as a personal RINEX header skeleton file for the corresponding stream.
     1345Whenever BNC starts to generate RINEX Observation files (and then once every day at midnight), it first tries to retrieve information needed for RINEX headers from so-called public RINEX header skeleton files which are derived from sitelogs. An HTTP or HTTPS link to a directory containing these skeleton files may be available through data field number 7 of the affected NET record in the source-table. See <u>http://www.epncb.oma.be:80/stations/log/skl/brus.skl</u> for an example of a public RINEX header skeleton file for EPN station Brussels. Note that the download of RINEX skeleton files from HTTPS websites requires the exchange of client and/or server certificates. Clarify 'SSL' options offered through panel 'Network' for details.
     1346</p>
     1347<p>
     1348Sometimes public RINEX header skeleton files are not available, their content is not up to date, or you need to put additional/optional records in the RINEX header. For that, BNC allows using personal skeleton files that contain the header records you would like to include. You can derive a personal RINEX header skeleton file from the information given in an up to date sitelog. A file in the RINEX Observations 'Directory' with a 'Skeleton extension' suffix is interpreted by BNC as a personal RINEX header skeleton file for the corresponding stream.
    13491349</p>
    13501350<p>
     
    13781378<br>- &nbsp; SYS / # / OBS TYPES (for RINEX Version 3 files, will be ignored when writing Version 2 files)</li>
    13791379<li>They may contain any other optional complete header record as defined in the RINEX documentation.</li>
    1380 <li>They should also contain an empty header records of type
     1380<li>They should also contain an empty header record of type
    13811381<br>- &nbsp; # / TYPES OF OBSERV (only RINEX Version 2, will be ignored when writing RINEX Version 3 files)
    13821382<br>BNC will include these lines in the final RINEX file header together with an additional
     
    14451445<li>When editing or concatenating RINEX 3 files to save them in Version 2 format, see section on 'RINEX Editing & QC'.</li>
    14461446</ol>
    1447 As the Version 2 format ignores signal generation attributes, BNC is forced to somehow map RINEX Version 3 to RINEX Version 2 although this can't be done in one-to-one correspondence. Hence we introduce a 'Signal priority' list of attributes (characters, forming a string) for mapping Version 3 to Version 2.
     1447As the Version 2 format ignores signal generation attributes, BNC is forced to somehow map RINEX Version 3 to RINEX Version 2 although this cannot be done in one-to-one correspondence. Hence we introduce a 'Signal priority' list of attributes (characters, forming a string) for mapping Version 3 to Version 2.
    14481448</p>
    14491449<p>
     
    14661466</p>
    14671467<p>
    1468 You may like to specify you own 'Signal priority' string(s) for producing RINEX Version 2 files. If you neither convert observation streams to RINEX Version 2 nor concatenate RINEX Version 3 to Version 2 files, then the 'Version 2' option is meaningless.
     1468You may like to specify your own 'Signal priority' string(s) for producing RINEX Version 2 files. If you neither convert observation streams to RINEX Version 2 nor concatenate RINEX Version 3 to Version 2 files, then the 'Version 2' option is meaningless.
    14691469</p>
    14701470
     
    14751475
    14761476<p>
    1477 Note that it is possible to force a RTCM Version 2 stream to be saved in RINEX Version 3 file format. However, this is not recommended because such stream cannot be precisely mapped to RINEX Version 3 as the required information on tracking modes (observation attributes) is not part of RTCM Version 2.
     1477Note that it is possible to force an RTCM Version 2 stream to be saved in RINEX Version 3 file format. However, this is not recommended because such stream cannot be precisely mapped to RINEX Version 3 as the required information on tracking modes (observation attributes) is not part of RTCM Version 2.
    14781478</p>
    14791479
     
    15331533</p>
    15341534<p>
    1535 Note that this does not concern the Broadcast Ephemeris output through IP port which is always in RINEX Version 3.03 format.
     1535Note that this does not concern the Broadcast Ephemeris output through IP port, which is always in RINEX Version 3.03 format.
    15361536</p>
    15371537
     
    15771577</p>
    15781578<p>
    1579 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 specific set of adjusted observation type records in the RINEX header which fits to the whole file content.
     1579When 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 specific set of adjusted observation type records in the RINEX header, which fits to the whole file content.
    15801580</p>
    15811581<p>
     
    15941594
    15951595<p>
    1596 Note that logfiles from analyzing RINEX files may become quite large. Hence BNC provides an option 'Summary only' to limit this logfile content to some essential information in case 'Action' is set to 'Analyze'. The following is an example for a RINEX quality check analysis logfile:
     1596Note that logfiles from analyzing RINEX files may become quite large. Hence, BNC provides an option 'Summary only' to limit this logfile content to some essential information in case 'Action' is set to 'Analyze'. The following is an example for a RINEX quality check analysis logfile:
    15971597<pre>
    15981598QC Format Version  : 1.0
     
    18411841<p>
    18421842<ul>
    1843 <li>The RINEX Version 2 format ignores signal generation attributes. Therefore, when converting <u>RINEX Version 3 to Version 2</u> Observation files, BNC is forced to somehow map signals with attributes to signals without attributes although this can't be done in one-to-one correspondence. Hence we introduce a 'Version 2 Signal Priority' list of attributes (characters, forming a string) for mapping Version 3 to Version 2, see details in section 'RINEX Observations/Version 2'. The default 'Version 2 Signal Priority' list of observation attributes when mapping RINEX Version 3 to Version 2 is 'CWPX_?'. Signal priorities can be specified either as equal for all systems or system specific. The following are example priority strings:</li>
     1843<li>The RINEX Version 2 format ignores signal generation attributes. Therefore, when converting <u>RINEX Version 3 to Version 2</u> Observation files, BNC is forced to somehow map signals with attributes to signals without attributes although this cannot be done in one-to-one correspondence. Hence we introduce a 'Version 2 Signal Priority' list of attributes (characters, forming a string) for mapping Version 3 to Version 2, see details in section 'RINEX Observations/Version 2'. The default 'Version 2 Signal Priority' list of observation attributes when mapping RINEX Version 3 to Version 2 is 'CWPX_?'. Signal priorities can be specified either as equal for all systems or system specific. The following are example priority strings:</li>
    18441844<ul>
    18451845<li>CWPX_? (Same signal priorities valid for all systems)</li>
     
    19691969<p><h4>2.7 <a name="sp3comp">SP3 Comparison</h4></p>
    19701970<p>
    1971 BNC allows to compare the contents of two files containing GNSS orbit and clock data in SP3 format. SP3 ASCII files basically contain a list of records over a certain period of time. Each record carries a time tag, the XYZ position of the satellite's Center of Mass at that time and the corresponding satellite clock value. Both SP3 files may contain some records for different epochs. If so then BNC only compares records for identical epochs. BNC accepts that a specific GNSS system or a specific satellite is only available from one of the SP3 files. Note that BNC does not interpolate orbits when comparing SP3 files.
     1971BNC allows to compare the contents of two files containing GNSS orbit and clock data in SP3 format. SP3 ASCII files basically contain a list of records over a certain period of time. Each record carries a time tag, the XYZ position of the satellite's Center of Mass at that time and the corresponding satellite clock value. Both SP3 files may contain some records for different epochs. If so, then BNC only compares records for identical epochs. BNC accepts that a specific GNSS system or a specific satellite is only available from one of the SP3 files. Note that BNC does not interpolate orbits when comparing SP3 files.
    19721972</p>
    19731973<p>
     
    20852085</p>
    20862086<p>
    2087 An alternative to the observation space approach is the so-called 'sate space' approach. The principle here is to provide information on individual error sources. It can be called 'State Space Representation' (SSR). For a rover position, state space information concerning precise satellite clocks, orbits, ionosphere, troposphere et cetera can be converted into observation space and used to correct the rover observables for more accurate positioning. Alternatively, the state information can be used directly in the rover's processing or adjustment model.
     2087An alternative to the observation space approach is the so-called 'state space' approach. The principle here is to provide information on individual error sources. It can be called 'State Space Representation' (SSR). For a rover position, state space information concerning precise satellite clocks, orbits, ionosphere, troposphere et cetera can be converted into observation space and used to correct the rover observables for more accurate positioning. Alternatively, the state information can be used directly in the rover's processing or adjustment model.
    20882088</p>
    20892089<p>
     
    21242124
    21252125<p>
    2126 The orbit and clock corrections do not include local effects like Ocean Loading, Solid Earth Tides or tropospheric delays. However, accurate single frequency applications can be correct for global ionospheric effects using so-call VTEC messages for global ionospheric state parameters.
    2127 </p>
    2128 
    2129 <p>
    2130 While we have a plain ASCII standard for saving Broadcast Ephemeris in RINEX Navigation files, we don't 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'.
     2126The orbit and clock corrections do not include local effects like Ocean Loading, Solid Earth Tides or tropospheric delays. However, accurate single frequency applications can be corrected for global ionospheric effects using so-call VTEC messages for global ionospheric state parameters.
     2127</p>
     2128
     2129<p>
     2130While 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'.
    21312131</p>
    21322132
     
    24492449
    24502450<p>
    2451 The following is an example for file and IP port output which presents observations from GPS, GLONASS, Galileo, BDS (BeiDou), QZSS, and SBAS satellites as collected through streams WTZR0, CUT07, and COCO0:
     2451The following is an example for file and IP port output, which presents observations from GPS, GLONASS, Galileo, BDS (BeiDou), QZSS, and SBAS satellites as collected through streams WTZR0, CUT07, and COCO0:
    24522452<pre>
    24532453> 1850 120556.0000000
     
    25192519<p><h4>2.9.1 <a name="syncport">Port - optional</h4></p>
    25202520<p>
    2521 BNC can produce synchronized observations in ASCII format on your local host (IP 127.0.0.1) through an IP 'Port'. Synchronized means that BNC collects all observation data for a specific epoch which become available within a certain number of seconds (see 'Wait for Full Obs Epoch' option). It then - epoch by epoch - outputs whatever has been received. The output comes block-wise per stream. Specify an IP port number here to activate this function. The default is an empty option field, meaning that no binary synchronized output is generated.</p>
     2521BNC can produce synchronized observations in ASCII format on your local host (IP 127.0.0.1) through an IP 'Port'. Synchronized means that BNC collects all observation data for a specific epoch, which become available within a certain number of seconds (see 'Wait for Full Obs Epoch' option). It then - epoch by epoch - outputs whatever has been received. The output comes block-wise per stream. Specify an IP port number here to activate this function. The default is an empty option field, meaning that no binary synchronized output is generated.</p>
    25222522</p>
    25232523
     
    25502550<p><h4>2.10 <a name="serial">Serial Output</h4></p>
    25512551<p>
    2552 You may use BNC to feed a serial connected device like a GNSS receiver. For that an incoming stream can be forwarded to a serial port. Depending on the stream content, the receiver may use it for Differential GNSS, Precise Point Positioning or any other purpose supported by its firmware.
     2552You may use BNC to feed a serially connected device like a GNSS receiver. For that, an incoming stream can be forwarded to a serial port. Depending on the stream content, the receiver may use it for Differential GNSS, Precise Point Positioning or any other purpose supported by its firmware.
    25532553</p>
    25542554<p>
     
    25572557
    25582558<p><img src="IMG/screenshot35.png"/></p>
    2559 <p><u>Figure 19:</u> Flowcharts, BNC forwarding a stream to a serial connected receiver; sending NMEA sentences is mandatory for VRS streams</p>
    2560 
    2561 <p>
    2562 The following figure shows the screenshot of an example situation where BNC pulls a VRS stream from an Ntrip Broadcaster to feed a serial connected RTK rover.
     2559<p><u>Figure 19:</u> Flowcharts, BNC forwarding a stream to a serially connected receiver; sending NMEA sentences is mandatory for VRS streams</p>
     2560
     2561<p>
     2562The following figure shows the screenshot of an example situation where BNC pulls a VRS stream from an Ntrip Broadcaster to feed a serially connected RTK rover.
    25632563</p>
    25642564
    25652565<p><img src="IMG/screenshot11.png"/></p>
    2566 <p><u>Figure 20:</u> BNC pulling a VRS stream to feed a serial connected RTK rover</p>
     2566<p><u>Figure 20:</u> BNC pulling a VRS stream to feed a serially connected RTK rover</p>
    25672567
    25682568<p><h4>2.10.1 <a name="sermount">Mountpoint - optional</h4></p>
    25692569<p>
    2570 Enter a 'Mountpoint' to forward its corresponding stream to a serial connected GNSS receiver.
    2571 </p>
    2572 <p>
    2573 When selecting one of the serial communication options listed below, make sure that you pick those configured to the serial connected receiver.
     2570Enter a 'Mountpoint' to forward its corresponding stream to a serially connected GNSS receiver.
     2571</p>
     2572<p>
     2573When selecting one of the serial communication options listed below, make sure that you pick those configured to the serially connected receiver.
    25742574</p>
    25752575
    25762576<p><h4>2.10.2 <a name="serport">Port Name - mandatory if 'Mountpoint' is set</h4></p>
    25772577<p>
    2578 Enter the serial 'Port name' selected on your host for communication with the serial connected receiver. Valid port names are
     2578Enter the serial 'Port name' selected on your host for communication with the serially connected receiver. Valid port names are
    25792579</p>
    25802580<pre>
     
    25982598<p><h4>2.10.4 <a name="serflow">Flow Control - mandatory if 'Mountpoint' is set</h4></p>
    25992599<p>
    2600 Select a 'Flow control' for the serial output link. Note that your selection must equal the flow control configured to the serial connected device. Select 'OFF' if you don't know better.
     2600Select a 'Flow control' for the serial output link. Note that your selection must equal the flow control configured to the serially connected device. Select 'OFF' if you do not know better.
    26012601</p>
    26022602
     
    26172617
    26182618<p><h4>2.10.8 <a name="serauto">NMEA - mandatory if 'Mountpoint' is set</h4></p>
    2619 <p>The 'NMEA' option supports the so-called 'Virtual Reference Station' (VRS) concept which requires the receiver to send approximate position information to the Ntrip Broadcaster. Select 'no' if you don't want BNC to forward or upload any NMEA sentence to the Ntrip broadcaster in support of VRS.
    2620 </p>
    2621 <p>Select 'Auto' to automatically forward NMEA sentences of type GGA from your serial connected receiver to the Ntrip broadcaster and/or save them in a file.
    2622 </p>
    2623 <p>Select 'Manual GPGGA' or 'Manual GNGGA' if you want BNC to produce and upload GPGGA or GNGGA NMEA sentences to the Ntrip broadcaster because your serial connected receiver doesn't generate them. A Talker ID 'GP' proceeding the GGA string stands for GPS solutions while a Talker ID 'GN' stands for multi-constellation solutions.
     2619<p>The 'NMEA' option supports the so-called 'Virtual Reference Station' (VRS) concept which requires the receiver to send approximate position information to the Ntrip Broadcaster. Select 'no' if you do not want BNC to forward or upload any NMEA sentence to the Ntrip broadcaster in support of VRS.
     2620</p>
     2621<p>Select 'Auto' to automatically forward NMEA sentences of type GGA from your serially connected receiver to the Ntrip broadcaster and/or save them in a file.
     2622</p>
     2623<p>Select 'Manual GPGGA' or 'Manual GNGGA' if you want BNC to produce and upload GPGGA or GNGGA NMEA sentences to the Ntrip broadcaster because your serially connected receiver does not generate them. A Talker ID 'GP' proceeding the GGA string stands for GPS solutions while a Talker ID 'GN' stands for multi-constellation solutions.
    26242624</p>
    26252625<p>Note that selecting 'Auto' or 'Manual' works only for VRS streams which show up under the 'Streams' canvas on BNC's main window with 'nmea' stream attribute set to 'yes'. This attribute is either extracted from the Ntrip broadcaster's source-table or introduced by the user through editing the BNC configuration file.
     
    26272627
    26282628<p><h4>2.10.9 <a name="serfile">File - optional if 'NMEA' is set to 'Auto'</h4></p>
    2629 <p>Specify the full path to a file where NMEA sentences coming from your serial connected receiver are saved. Default is an empty option field, meaning that no NMEA sentences will be saved on disk.
     2629<p>Specify the full path to a file where NMEA sentences coming from your serially connected receiver are saved. Default is an empty option field, meaning that no NMEA sentences will be saved on disk.
    26302630</p>
    26312631<p><h4>2.10.10 <a name="serheight">Height - mandatory if 'NMEA' is set to 'Manual'</h4></p>
     
    26622662<p><h4>2.11.1 <a name="obsrate">Observation Rate - optional</h4></p>
    26632663<p>
    2664 BNC can collect all returns (success or failure) coming from a decoder within a certain short time span to then decide whether a stream has an outage or its content is corrupted. This procedure needs a rough a priori estimate of the expected observation rate of the incoming streams.</p><p>An empty option field (default) means that you don't want explicit information from BNC about stream outages and incoming streams that cannot be decoded.
     2664BNC can collect all returns (success or failure) coming from a decoder within a certain short time span to then decide whether a stream has an outage or its content is corrupted. This procedure needs a rough a priori estimate of the expected observation rate of the incoming streams.</p><p>An empty option field (default) means that you do not want explicit information from BNC about stream outages and incoming streams that cannot be decoded.
    26652665</p>
    26662666
     
    27112711</p>
    27122712<p>
    2713 Note the sleep command in this script which causes the system to wait for a random period of up to 60 seconds before sending the email. This should avoid overloading your mail server in case of a simultaneous failure of many streams.
     2713Note the sleep command in this script, which causes the system to wait for a random period of up to 60 seconds before sending the email. This should avoid overloading your mail server in case of a simultaneous failure of many streams.
    27142714</p>
    27152715
    27162716<p><h4>2.12 <a name="misc">Miscellaneous</h4></p>
    27172717<p>
    2718 This section describes several miscellaneous options which can be applied to a single stream (mountpoint) or to all configured streams.
     2718This section describes several miscellaneous options, which can be applied to a single stream (mountpoint) or to all configured streams.
    27192719</p>
    27202720
     
    27282728<p><h4>2.12.1 <a name="miscmount">Mountpoint - optional </h4></p>
    27292729<p>
    2730 Specify a mountpoint to apply one or several of the 'Miscellaneous' options to the corresponding stream. Enter 'ALL' if you want to apply these options to all configured streams. An empty option field (default) means that you don't want BNC to apply any of these options.
     2730Specify a mountpoint to apply one or several of the 'Miscellaneous' options to the corresponding stream. Enter 'ALL' if you want to apply these options to all configured streams. An empty option field (default) means that you do not want BNC to apply any of these options.
    27312731</p>
    27322732
     
    27842784
    27852785<p>
    2786 Please note further that RTCM Version 3 message types 1084 for GLONASS don't 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.
     2786Please 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.
    27872787</p>
    27882788<p>
     
    27902790<p>Logged time stamps refer to message reception time and allow understanding repetition rates. Enter 'ALL' if you want to log this information from all configured streams. Beware that the size of the logfile can rapidly increase depending on the number of incoming RTCM streams.
    27912791</p>
    2792 <p>This option is primarily meant for test and evaluation. Use it to figure out what exactly is produced by a specific GNSS receiver's configuration. An empty option field (default) means that you don't want BNC to print message type numbers and antenna information carried in RTCM streams.
     2792<p>This option is primarily meant for test and evaluation. Use it to figure out what exactly is produced by a specific GNSS receiver's configuration. An empty option field (default) means that you do not want BNC to print message type numbers and antenna information carried in RTCM streams.
    27932793</p>
    27942794
     
    28022802</p>
    28032803<p>
    2804  An empty option field (default) means that you don't want BNC to apply the TCP/IP port output option.
     2804 An empty option field (default) means that you do not want BNC to apply the TCP/IP port output option.
    28052805</p>
    28062806
     
    28612861</p>
    28622862<p>
    2863 If you don't pull Broadcast Corrections, BNC will switch with its solution to 'Single Point Positioning' (SPP) mode.
     2863If you do not pull Broadcast Corrections, BNC will switch with its solution to 'Single Point Positioning' (SPP) mode.
    28642864</p>
    28652865
     
    28962896</p>
    28972897<p>
    2898 If you don't specify a 'Corrections stream' BNC will fall back from a PPP solution to a Single Point Positioning (SPP) solution.
     2898If you do not specify a 'Corrections stream' BNC will fall back from a PPP solution to a Single Point Positioning (SPP) solution.
    28992899</p>
    29002900
     
    29042904</p>
    29052905<p>
    2906 If you don't specify a 'Correction file', BNC will fall back from a PPP solution to a Single Point Positioning (SPP) solution.
     2906If you do not specify a 'Correction file', BNC will fall back from a PPP solution to a Single Point Positioning (SPP) solution.
    29072907</p>
    29082908
     
    29122912</p>
    29132913<p>
    2914 Default value for 'ANTEX file' is an empty option field, meaning that you don't want to correct observations for Antenna Phase Center offsets and variations.
     2914Default value for 'ANTEX file' is an empty option field, meaning that you do not want to correct observations for Antenna Phase Center offsets and variations.
    29152915</p>
    29162916
     
    29302930<li>Only for static observations from a stationary receiver:<br>Approximate a priori XYZ coordinate [m] of the station's marker; specify '0.0 0.0 0.0' if unknown or when observations come from a mobile receiver.</li><br>
    29312931<li>Nort, East and Up component [m] of antenna eccentricity which is the difference between Antenna Reference Point (ARP) and a nearby marker position; when specifying the antenna eccentricity BNC will produce coordinates referring to the marker position and not referring to ARP; specify '0.0 0.0 0.0' if eccentricity is unknown or the ARP itself is understood as the marker.</li><br>
    2932 <li>Receiver's antenna name as defined in your ANTEX file (see below); Observations will be corrected for the Antenna Phase Center (APC) offsets and variations which may result in a reduction of a few centimeters at max; the specified name must consist of 20 characters; add trailing blanks if the antenna name has less than 20 characters; examples:<br><pre>
     2932<li>Receiver's antenna name as defined in your ANTEX file (see below); Observations will be corrected for the Antenna Phase Center (APC) offsets and variations, which may result in a reduction of a few centimeters at max; the specified name must consist of 20 characters; add trailing blanks if the antenna name has less than 20 characters; examples:<br><pre>
    29332933&nbsp; &nbsp;'JPSREGANT_SD_E      ' (no radome)
    29342934&nbsp; &nbsp;'LEIAT504        NONE' (no radome)
    29352935&nbsp; &nbsp;'LEIAR25.R3      LEIT' (radome)</pre>
    2936 Leave antenna name blank if you don't want to correct observations for APC offsets and variations or if you don't know the antenna name.</li><br>
     2936Leave antenna name blank if you do not want to correct observations for APC offsets and variations or if you do not know the antenna name.</li><br>
    29372937<li>
    29382938Receiver type following the naming convention for IGS equipment as defined in <u>https://igscb.jpl.nasa.gov/igscb/station/general/rcvr_ant.tab</u>. Specifying the receiver type is only required when saving SINEX Troposphere files. In those files it becomes part of the 'SITE/RECEIVER' specifications, see section 'SNX TRO Directory'.
     
    30023002</p>
    30033003<ul>
    3004 <li> Record 'WTZR0' describes a stream from a stationary receiver with known a priori marker coordinate, antenna eccentricity, antenna and radome type and receiver tpye.</li>
     3004<li> Record 'WTZR0' describes a stream from a stationary receiver with known a priori marker coordinate, antenna eccentricity, antenna and radome type and receiver type.</li>
    30053005<li> Record 'CUT07' describes a stream from a stationary receiver with known a priori marker coordinate, antenna eccentricity and antenna and radome type. The receiver type is unknown.</li>
    30063006<li> Record 'FFMJ1' describes a stream from a stationary receiver with known a priori marker coordinate and antenna eccentricity but unknown antenna, radome and receiver type.</li>
     
    31533153</pre>
    31543154<p>
    3155  Depending on selected processing options you find 'GPS Time' stampes (yyyy-mm-dd_hh:mm:ss.sss) followed by
     3155 Depending on selected processing options you find 'GPS Time' stamps (yyyy-mm-dd_hh:mm:ss.sss) followed by
    31563156<ul>
    31573157<li>RES: Code and phase residuals for contributing GNSS systems in [m]<br>Given per satellite with cIF/lIF for ionosphere-free linear combination of code/phase observations,</li>
     
    31673167</p>
    31683168<p>
    3169 Default value for 'Logfile directory' is an empty option field, meaning that you don't want to save daily PPP logfiles on disk. If a specified directory does not exist, BNC will not create PPP logfiles.
     3169Default value for 'Logfile directory' is an empty option field, meaning that you do not want to save daily PPP logfiles on disk. If a specified directory does not exist, BNC will not create PPP logfiles.
    31703170</p>
    31713171
     
    33053305</p>
    33063306<p>
    3307 Default 'Sampling' rate is '0', meaning that all troposphere estimates will be save on disk.
     3307Default 'Sampling' rate is '0', meaning that all troposphere estimates will be saved on disk.
    33083308</p>
    33093309
     
    33303330<p><h4>2.13.2.2 <a name="pppnehsigma">Sigma North/East/Up - mandatory</h4></p>
    33313331<p>
    3332 Enter a sigmas in meters for the initial coordinate components. A value of 100.0 (default) may be an appropriate choice. However, this value may be significantly smaller (e.g. 0.01) when starting for example from a station with a well-known position in so-called Quick-Start mode.
     3332Enter sigmas in meters for the initial coordinate components. A value of 100.0 (default) may be an appropriate choice. However, this value may be significantly smaller (e.g. 0.01) when starting for example from a station with a well-known position in so-called Quick-Start mode.
    33333333</p>
    33343334
     
    33813381</ul>
    33823382</p>
    3383 <p>Note that most geodetic GPS receivers support the observation of both, code and phase data. Hence specifying 'P3&L3' would be a good choice for GPS when processing data from such a receiver. If multi-GNSS data processing is your intention, make sure your receiver supports GLONASS and/or Galileo and/or BDS observations besides GPS. Note also that the Broadcast Correction stream or file which is required for PPP also supports all the systems you have in mind.
    3384 </p>
    3385 <p>Specifying 'no' means that you don't at all want BNC to use observations from the affected GNSS system.
     3383<p>Note that most geodetic GPS receivers support the observation of both, code and phase data. Hence, specifying 'P3&L3' would be a good choice for GPS when processing data from such a receiver. If multi-GNSS data processing is your intention, make sure your receiver supports GLONASS and/or Galileo and/or BDS observations besides GPS. Note also that the Broadcast Correction stream or file, which is required for PPP, also supports all the systems you have in mind.
     3384</p>
     3385<p>Specifying 'no' means that you do not at all want BNC to use observations from the affected GNSS system.
    33863386</p>
    33873387
     
    34043404
    34053405<p>
    3406 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.
    3407 <ul>
    3408 <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 till you finally get the best possible solution.</li>
     3406As 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.
     3407<ul>
     3408<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 untill you finally get the best possible solution.</li>
    34093409<li>Introducing a bigger 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>
    34103410</ul>
     
    34443444<p><h4>2.13.3.7 <a name="pppwaitclockcorr">Wait for Clock Corrections - optional</h4></p>
    34453445<p>
    3446 Specifying 'no' for option 'Wait for clock corr.' means that BNC processes each epoch of data immediately after its arrival using satellite clock corrections available at that time. A non-zero value means that epochs of data are buffered and the processing of each epoch is postponed till satellite clock corrections not older than 'Wait for clock corr.' seconds are available. Specifying a value of half the update rate of the clock corrections (e.g. 5 sec) may be appropriate. Note that this causes an additional delay of the PPP solutions in the amount of half of the update rate.
     3446Specifying 'no' for option 'Wait for clock corr.' means that BNC processes each epoch of data immediately after its arrival using satellite clock corrections available at that time. A non-zero value means that epochs of data are buffered and the processing of each epoch is postponed untill satellite clock corrections not older than 'Wait for clock corr.' seconds are available. Specifying a value of half the update rate of the clock corrections (e.g. 5 sec) may be appropriate. Note that this causes an additional delay of the PPP solutions in the amount of half of the update rate.
    34473447</p>
    34483448<p>
     
    34553455<p><h4>2.13.3.8 <a name="pppseeding">Seeding - optional if a priori coordinates specified in 'Coordinates file'</h4></p>
    34563456<p>
    3457 Enter the length of a startup period in seconds for which you want to fix the PPP solution to an known position, see option 'Coordinates file'. Constraining a priori coordinates is done in BNC through setting their white 'Noise' temporarily to zero.
    3458 </p>
    3459 <p>
    3460 This so-called Quick-Start option allows the PPP solutions to rapidly converge after startup. It requires that the antenna remains unmoved on the known position throughout the defined period. A value of '60' seconds is likely to be an appropriate choice for 'Seeding'. Default is an empty option field, meaning that you don't want BNC to start in Quick-Start mode.
    3461 <p>
    3462 You may need to create your own reference coordinate beforehand through running BNC for an hour in normal mode before applying the 'Seeding' option. Don't forget to introduce realistic North/East/Up sigmas under panel 'PPP (2)' corresponding to the coordinate's precision.
    3463 </p>
    3464 
    3465 <p>
    3466 'Seeding' has also a function for bridging gaps in PPP solutions from failures caused e.g. by longer lasting outages. Should the time span between two consecutive solutions exceed the limit of 60 seconds (maximum solution gap, hard-wired), the algorithm fixes the latest derived coordinate for a period of 'Seeding' seconds. This option avoids time-consuming reconvergences and makes especially sense for stationary operated receivers where convergence can be enforced because a good approximation for the receiver position is known. 
     3457Enter the length of a startup period in seconds for which you want to fix the PPP solution to a known position, see option 'Coordinates file'. Constraining a priori coordinates is done in BNC through setting their white 'Noise' temporarily to zero.
     3458</p>
     3459<p>
     3460This so-called Quick-Start option allows the PPP solutions to rapidly converge after startup. It requires that the antenna remains unmoved on the known position throughout the defined period. A value of '60' seconds is likely to be an appropriate choice for 'Seeding'. Default is an empty option field, meaning that you do not want BNC to start in Quick-Start mode.
     3461<p>
     3462You may need to create your own reference coordinate beforehand through running BNC for an hour in normal mode before applying the 'Seeding' option. Do not forget to introduce realistic North/East/Up sigmas under panel 'PPP (2)' corresponding to the coordinate's precision.
     3463</p>
     3464
     3465<p>
     3466'Seeding' has also a function for bridging gaps in PPP solutions from failures caused e.g. by longer lasting outages. Should the time span between two consecutive solutions exceed the limit of 60 seconds (maximum solution gap, hard-wired), the algorithm fixes the latest derived coordinate for a period of 'Seeding' seconds. This option avoids time-consuming reconvergences and makes especially sense for stationarily operated receivers where convergence can be enforced because a good approximation for the receiver position is known. 
    34673467</p>
    34683468
     
    34843484</p>
    34853485<p>
    3486 Note that a PPP dicplacements time series makes only sense for a stationary operated receiver.
     3486Note that a PPP dicplacements time series makes only sense for a stationarily operated receiver.
    34873487</p>
    34883488
    34893489<p><h4>2.13.4.2 <a name="pppaudioresp">Audio Response - optional</h4></p>
    34903490<p>
    3491 For natural hazard prediction and monitoring landslides it may be appropriate to generate audio alerts. For that you can specify an 'Audio response' threshold in meters. A beep is produced by BNC whenever a horizontal PPP coordinate component differs by more than the threshold value from the specified marker coordinate.
    3492 </p>
    3493 <p>
    3494 Default is an empty option field, meaning that you don't want BNC to produce acoustic warnings.
     3491For natural hazard prediction and monitoring landslides, it may be appropriate to generate audio alerts. For that you can specify an 'Audio response' threshold in meters. A beep is produced by BNC whenever a horizontal PPP coordinate component differs by more than the threshold value from the specified marker coordinate.
     3492</p>
     3493<p>
     3494Default is an empty option field, meaning that you do not want BNC to produce acoustic warnings.
    34953495</p>
    34963496
     
    35243524<p><h4>2.13.4.4.1 <a name="pppdotsize">Size - mandatory before pushing 'Open Map'</h4></p>
    35253525<p>
    3526 Specify the size of dots showing the rover position. A dot size of '3' may be appropriate. The maximum possible dot size is '10'. An empty option field or a size of '0' would mean that you don't want BNC to show the rover's track on the map.
     3526Specify the size of dots showing the rover position. A dot size of '3' may be appropriate. The maximum possible dot size is '10'. An empty option field or a size of '0' would mean that you do not want BNC to show the rover's track on the map.
    35273527</p>
    35283528
     
    35423542</p>
    35433543<p>
    3544 In the Kalman Filter approach, satellite clocks estimated by individual Analyses Centers (ACs) are used as pseudo observations within the adjustment process. Each observation is modeled as a linear function (actually a simple sum) of three estimated parameters: AC specific offset, satellite specific offset common to all ACs, and the actual satellite clock correction which represents the result of the combination. These three parameter types differ in their statistical properties. The satellite clock offsets are assumed to be static parameters while AC specific and satellite specific offsets are stochastic parameters with appropriate white noise.
     3544In the Kalman Filter approach, satellite clocks estimated by individual Analyses Centers (ACs) are used as pseudo observations within the adjustment process. Each observation is modeled as a linear function (actually a simple sum) of three estimated parameters: AC specific offset, satellite specific offset common to all ACs, and the actual satellite clock correction, which represents the result of the combination. These three parameter types differ in their statistical properties. The satellite clock offsets are assumed to be static parameters while AC specific and satellite specific offsets are stochastic parameters with appropriate white noise.
    35453545 The solution is regularized by a set of minimal constraints. After a change of one of the three values 'SSR Provider ID', 'SSR Solution ID', or 'IOD SSR', the satellite clock offsets belonging to the corresponding analysis center are reset in the adjustment.
    35463546</p>
     
    35623562</p>
    35633563<p>
    3564 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. Note further that BNC will ignore incorrect or outdated Broadcast Ephemeris data when necessary, leaving a note 'WRONG EPHEMERIS' or 'OUTDATED EPHEMERIS' in the logfile.
     3564Note that the combination process requires real-time access to Broadcast Ephemeris. Therefore, 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. Note further that BNC will ignore incorrect or outdated Broadcast Ephemeris data when necessary, leaving a note 'WRONG EPHEMERIS' or 'OUTDATED EPHEMERIS' in the logfile.
    35653565</p>
    35663566
     
    35703570
    35713571<p>
    3572 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.
     3572With 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.
    35733573</p>
    35743574<p>
     
    35783578The following recursive algorithm is used to detect orbit outliers in the Kalman Filter combination when Broadcast Corrections are provided by several ACs:
    35793579<br>
    3580 Step 1: We don't produce a combination for a certain satellite if only one AC provides corrections for it.
     3580Step 1: We do not produce a combination for a certain satellite if only one AC provides corrections for it.
    35813581<br>
    35823582Step 2: A mean satellite position is calculated as the average of positions from all ACs.
    35833583<br>
    3584 Step 3: For each AC and satellite the 3D distance between individual and mean satellite position is calculated.
     3584Step 3: For each AC and satellite, the 3D distance between individual and mean satellite position is calculated.
    35853585<br>
    35863586Step 4: We find the greatest difference between AC specific and mean satellite positions.
    35873587<br>
    3588 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.
     3588Step 5: If that is less than a threshold, the conclusion is that we do not have an outlier and can proceed to the next epoch.
    35893589<br>
    35903590Step 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.
     
    35993599</p>
    36003600<p>
    3601 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>
     3601The 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>
    36023602<p>
    36033603It is possible to specify only one Broadcast Ephemeris correction 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' panel. Note that in such a BNC application you must not pull more than one Broadcast Ephemeris correction stream even if a second stream would provide the same corrections from a backup caster.
    36043604</p>
    36053605<p>
    3606 Default is an empty 'Combine Corrections' table meaning that you don't want BNC to combine orbit and clock correction streams.
     3606Default is an empty 'Combine Corrections' table meaning that you do not want BNC to combine orbit and clock correction streams.
    36073607</p>
    36083608
     
    36133613
    36143614<p>
    3615 The following screenshots describe an example setup of BNC when combining Broadcast Correction streams and uploading them to an Ntrip Broadcaster. Note that this application requires specifying options under panels 'Combine Corrections' and 'Upload Corrections'. The example uses the combination product to simultaneously carry out an 'INTERNAL' PPP solution which allows monitoring the quality of the combination product in the space domain.
     3615The following screenshots describe an example setup of BNC when combining Broadcast Correction streams and uploading them to an Ntrip Broadcaster. Note that this application requires specifying options under panels 'Combine Corrections' and 'Upload Corrections'. The example uses the combination product to simultaneously carry out an 'INTERNAL' PPP solution, which allows monitoring the quality of the combination product in the space domain.
    36163616</p>
    36173617
     
    37663766</p>
    37673767<p>
    3768 Having an empty 'Upload Table' is default and means that you don't want BNC to upload orbit and clock correction streams to any Ntrip Broadcaster.
     3768Having an empty 'Upload Table' is default and means that you do not want BNC to upload orbit and clock correction streams to any Ntrip Broadcaster.
    37693769</p>
    37703770
     
    39723972Note that '${GPSWD}' produces the GPS Week and Day number in the filename.</p>
    39733973<p>
    3974 Default is an empty option field, meaning that you don't want BNC to save the uploaded stream content in daily SP3 files.
    3975 </p>
    3976 <p>
    3977 As a SP3 file content should be referred to the satellites' Center of Mass (CoM) while Broadcast Corrections are referred to the satellites' APC, an offset has to be applied which is available from an IGS ANTEX file (see option 'ANTEX File' below). Hence you should specify the 'ANTEX File' path there if you want to save the stream content in SP3 format. If you don't specify an 'ANTEX File' path, the SP3 file content will be referred to the satellites APCs.
     3974Default is an empty option field, meaning that you do not want BNC to save the uploaded stream content in daily SP3 files.
     3975</p>
     3976<p>
     3977As a SP3 file content should be referred to the satellites' Center of Mass (CoM) while Broadcast Corrections are referred to the satellites' APC, an offset has to be applied which is available from an IGS ANTEX file (see option 'ANTEX File' below). Hence, you should specify the 'ANTEX File' path there if you want to save the stream content in SP3 format. If you do not specify an 'ANTEX File' path, the SP3 file content will be referred to the satellites APCs.
    39783978</p>
    39793979<p>
     
    40594059<p><h4>2.15.10 <a name="upantex">ANTEX File - mandatory if 'SP3 File' is specified</h4></p>
    40604060<p>
    4061 IGS provides a file containing absolute phase center variations for GNSS satellite and receiver antennas in ANTEX format. Entering the full path to such an ANTEX file is required here for referring the SP3 file content to the satellite's Center of Mass (CoM). If you don't specify a ANTEX file, the SP3 file will contain orbit information which is referred to Antenna Phase Center (APC) instead of CoM.
     4061IGS provides a file containing absolute phase center variations for GNSS satellite and receiver antennas in ANTEX format. Entering the full path to such an ANTEX file is required here for referring the SP3 file content to the satellite's Center of Mass (CoM). If you do not specify an ANTEX file, the SP3 file will contain orbit information which is referred to Antenna Phase Center (APC) instead of CoM.
    40624062</p>
    40634063
     
    40854085<p><h4>2.16.1 <a name="brdcserver">Host &amp; Port - optional</h4></p>
    40864086<p>
    4087 Specify the 'Host' IP number or URL of an Ntrip Broadcaster to upload the stream. An empty option field means that you don't want to upload Broadcast Ephemeris.
     4087Specify the 'Host' IP number or URL of an Ntrip Broadcaster to upload the stream. An empty option field means that you do not want to upload Broadcast Ephemeris.
    40884088</p>
    40894089<p>
     
    41314131</li>
    41324132<li>
    4133 In case you need to log the raw data as is, BNC allows users to by-pass its decoders and directly save the input in daily logfiles. To do this, specify the decoder string as 'ZERO'. The generated filenames are created from the characters of the streams mountpoints plus two-digit numbers each for year, month, and day. Example: Setting the 'decoder' string for mountpoint WTZZ0 to 'ZERO' and running BNC on March 29, 2007 would save the raw data in a file named WTZZ0_070329.
     4133In case you need to log the raw data as it is, BNC allows users to by-pass its decoders and directly save the input in daily logfiles. To do this, specify the decoder string as 'ZERO'. The generated filenames are created from the characters of the streams mountpoints plus two-digit numbers each for year, month, and day. Example: Setting the 'decoder' string for mountpoint WTZZ0 to 'ZERO' and running BNC on March 29, 2007 would save the raw data in a file named WTZZ0_070329.
    41344134</li>
    41354135<li>
    41364136BNC can also retrieve streams from virtual reference stations (VRS). To initiate these streams, an approximate rover position needs to be sent in NMEA format to the Ntrip Broadcaster. In return, a user-specific data stream is generated, typically by Network RTK software. VRS streams are indicated by a 'yes' in the source-table as well as in the 'nmea' column on the 'Streams' canvas in BNC's main window. They are customized exactly to the latitude and longitude transmitted to the Ntrip Broadcaster via NMEA GGA sentences.
    4137 <br>If NMEA GGA sentences are not coming from a serial connected GNSS rover, BNC simulates them from the default latitude and longitude of the source-table as shown in the 'lat' and 'long' columns on the 'Streams' canvas. However, in many cases you would probably want to change these defaults according to your requirement. Double-click on 'lat' and 'long' fields, enter the values you wish to send and then hit Enter. The format is in positive north latitude degrees (e.g. for northern hemisphere: 52.436, for southern hemisphere: -24.567) and eastern longitude degrees (example: 358.872 or -1.128). Only streams with a 'yes' in their 'nmea' column can be edited. The position must preferably be a point within the VRS service area of the network. RINEX files generated from these streams will contain an additional COMMENT line in the header beginning with 'NMEA' showing the 'lat' and 'long' used.
     4137<br>If NMEA GGA sentences are not coming from a serially connected GNSS rover, BNC simulates them from the default latitude and longitude of the source-table as shown in the 'lat' and 'long' columns on the 'Streams' canvas. However, in many cases you would probably want to change these defaults according to your requirement. Double-click on 'lat' and 'long' fields, enter the values you wish to send and then hit Enter. The format is in positive north latitude degrees (e.g. for northern hemisphere: 52.436, for southern hemisphere: -24.567) and eastern longitude degrees (example: 358.872 or -1.128). Only streams with a 'yes' in their 'nmea' column can be edited. The position must preferably be a point within the VRS service area of the network. RINEX files generated from these streams will contain an additional COMMENT line in the header beginning with 'NMEA' showing the 'lat' and 'long' used.
    41384138<br>Note that when running BNC in a Local Area Network (LAN), NMEA strings may be blocked by a proxy server, firewall or virus scanner when not using the Ntrip Version 2 transport protocol.
    41394139</li>
     
    41564156<p><h4>2.18 <a name="logs">Logging Canvas</h4></p>
    41574157<p>
    4158 The 'Logging Canvas' above the bottom menu bar on the main window labeled 'Log', 'Throughput', 'Lacenty', and 'PPP Plot' provides control of BNC's activities. Tabs are available for continuously showing logfile content, for a plot controlling the bandwidth consumption, a plot showing stream latencies, and for time series plots of PPP results.
     4158The 'Logging Canvas' above the bottom menu bar on the main window labeled 'Log', 'Throughput', 'Latency', and 'PPP Plot' provides control of BNC's activities. Tabs are available for continuously showing logfile content, for a plot controlling the bandwidth consumption, a plot showing stream latencies, and for time series plots of PPP results.
    41594159</p>
    41604160<p><h4>2.18.1 <a name="logfile">Log</h4></p>
     
    41814181<p><h4>2.18.4 <a name="ppptab">PPP Plot</h4></p>
    41824182<p>
    4183 Precise Point Positioning time series of North (red), East (green) and Up (blue) coordinate components are shown in the 'PPP Plot' tab when a 'Mountpoint' option is defined under PPP (4). Values are either referred to reference coordinates (if specified) or referred to the first estimated set of coordinate components. The time as given in format [hh:mm] refers to GPS Time. The sliding PPP time series window covers a period of 5 minutes. Note that it may take up to 30 seconds or more till the first PPP solutions becomes available. The following figure shows the screenshot of a PPP time series plot of North, East and Up coordinate displacements.
     4183Precise Point Positioning time series of North (red), East (green) and Up (blue) coordinate components are shown in the 'PPP Plot' tab when a 'Mountpoint' option is defined under PPP (4). Values are either referred to reference coordinates (if specified) or referred to the first estimated set of coordinate components. The time as given in format [hh:mm] refers to GPS Time. The sliding PPP time series window covers a period of 5 minutes. Note that it may take up to 30 seconds or more untill the first PPP solutions becomes available. The following figure shows the screenshot of a PPP time series plot of North, East and Up coordinate displacements.
    41844184</p>
    41854185
     
    41974197<p><h4>2.19.1 <a name="streamadd">Add Stream</h4></p>
    41984198<p>
    4199 Button 'Add Stream' allows you to pull streams either from a Ntrip Broadcaster or from a TCP/IP port, UPD port, or serial port.
     4199Button 'Add Stream' allows you to pull streams either from an Ntrip Broadcaster or from a TCP/IP port, UPD port, or serial port.
    42004200</p>
    42014201
     
    42334233</p>
    42344234<p>
    4235 Hit 'OK' to return to the main window. If you wish you can click on 'Add Stream' and repeat the process to retrieve streams from different casters.
     4235Hit 'OK' to return to the main window. If you wish, you can click on 'Add Stream' and repeat the process to retrieve streams from different casters.
    42364236</p>
    42374237<p><img src="IMG/screenshot05.png"/></p>
     
    42604260<ul>
    42614261<li>Try using option '2' if your streams are otherwise blocked by a proxy server operated in front of BNC.</li>
    4262 <li>When using Ntrip Version 2 via SSL (option '2s') you need to specify the appropriate 'Caster port' for that. It's usually port number 443. Clarify 'SSL' options offered in panel 'Network'.</li>
     4262<li>When using Ntrip Version 2 via SSL (option '2s') you need to specify the appropriate 'Caster port' for that. It is usually port number 443. Clarify 'SSL' options offered in panel 'Network'.</li>
    42634263<li>Option 'R' or 'U' may be selected if latency is more important than completeness for your application. Note that the latency reduction is likely to be in the order of 0.5 sec or less. Note further that options 'R' (RTSP/RTP mode) and 'U' (UDP mode) are not accepted by proxy servers and a mobile Internet Service Provider may not support it.</li>
    42644264</ul>
     
    43324332<li>Select the 'Parity' for the serial input. Note that parity is often set to 'NONE'.</li>
    43334333<li>Select the number of 'Stop bits' for the serial input. Note that often '1' stop bit is used.</li>
    4334 <li>Select a 'Flow control' for the serial link. Select 'OFF' if you don't know better.</li>
    4335 </ul>
    4336 </p>
    4337 <p>
    4338 When selecting one of the serial communication options listed above, make sure that you pick those configured to the serial connected GNSS receiver.
    4339 </p>
    4340 
    4341 <p>
    4342 Streams received from a serial connected GNSS receiver show up with an 'S' (for <u>S</u>erial Port, no Ntrip) in the 'Streams' canvas section on BNC's main window. Latitude and longitude are to be entered just for informal reasons.
     4334<li>Select a 'Flow control' for the serial link. Select 'OFF' if you do not know better.</li>
     4335</ul>
     4336</p>
     4337<p>
     4338When selecting one of the serial communication options listed above, make sure that you pick those configured to the serially connected GNSS receiver.
     4339</p>
     4340
     4341<p>
     4342Streams received from a serially connected GNSS receiver show up with an 'S' (for <u>S</u>erial Port, no Ntrip) in the 'Streams' canvas section on BNC's main window. Latitude and longitude are to be entered just for informal reasons.
    43434343<p>
    43444344
     
    44174417<p>
    44184418It is obvious that BNC requires graphics support when started in interactive
    4419 mode. But, note that graphics support is also required when producing plots in
     4419mode. However, note that graphics support is also required when producing plots in
    44204420batch mode (option -nw). Windows and Mac OS X systems always support graphics. For
    44214421producing plots in batch mode on Linux systems you must make sure that at
     
    46444644[Mod] PPP default options<br>
    46454645[Add] Example configuration for SP3 file comparison<br>
    4646 [Add] Chose between code and phase observations when in PPP SSR I mode<br>
     4646[Add] Choose between code and phase observations when in PPP SSR I mode<br>
    46474647[Bug] Reset time series plot when restarting PPP in post processing mode<br>
    46484648[Add] Broadcast ephemeris check regarding allowed age of data sets<br>
     
    47144714<li>Application not limited to one particular plain or coded stream content; ability to distribute any kind of GNSS data;</li>
    47154715<li>Potential to support mass usage; disseminating hundreds of streams simultaneously for thousands of users possible when applying modified Internet Radio broadcasting software;</li>
    4716 <li>Considering security needs; stream providers and users don't necessarily get into contact, streams often not blocked by firewalls or proxy servers protecting Local Area Networks;</li>
     4716<li>Considering security needs; stream providers and users do not necessarily get into contact, streams often not blocked by firewalls or proxy servers protecting Local Area Networks;</li>
    47174717<li>Enables streaming over mobile IP networks because of using TCP/IP.</li>
    47184718</ul>
     
    47414741<ul>
    47424742<li>Cleared and fixed design problems and HTTP protocol violations;</li>
    4743 <li>Replaced non standard directives;</li>
     4743<li>Replaced nonstandard directives;</li>
    47444744<li>Chunked transfer encoding;</li>
    47454745<li>Improvements in header records;</li>
     
    47484748</ul>
    47494749
    4750 <p>Ntrip Version 2 allows to either communicate in TCP/IP mode or in RTSP/RTP mode or in UDP mode whereas Version 1 is limited to TCP/IP only. It furthermore allows using the Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL) cryptographic protocols for secure Ntrip communication over the Internet.
     4750<p>Ntrip Version 2 allows to communicate either in TCP/IP mode or in RTSP/RTP mode or in UDP mode whereas Version 1 is limited to TCP/IP only. It furthermore allows using the Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL) cryptographic protocols for secure Ntrip communication over the Internet.
    47514751</p>
    47524752
Note: See TracChangeset for help on using the changeset viewer.