Changeset 4047 in ntrip
- Timestamp:
- Apr 24, 2012, 12:58:55 PM (12 years ago)
- File:
-
- 1 edited
-
trunk/BNC/bnchelp.html (modified) (65 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/BNC/bnchelp.html
r4046 r4047 3 3 4 4 <p> 5 The BKG Ntrip Client (BNC) is a program for simultaneously retrieving, decoding, converting and processing real-time GNSS data streams from NTRIP broadcasters like <u>http://www.euref-ip.net/home</u>, <u>http://www.igs-ip.net/home</u> or <u>http://products.igs-ip.net/home</u>. It furthermore allows to edit and concatenate RINEX files or check their quality.5 The BKG Ntrip Client (BNC) is a program for simultaneously retrieving, decoding, converting and processing real-time GNSS data streams from NTRIP Broadcasters like <u>http://www.euref-ip.net/home</u>, <u>http://www.igs-ip.net/home</u>, <u>http://products.igs-ip.net/home</u>, or <u>http://mgex.igs-ip.net/home</u>. It furthermore allows to edit and concatenate RINEX files or check their quality. 6 6 </p> 7 7 … … 39 39 <li>generate high-rate RINEX Observation and Navigation files to support near real-time GNSS post-processing applications,</li> 40 40 <li>generate ephemeris and synchronized or unsynchronized observations epoch by epoch through an IP port to support real-time GNSS network engines,</li> 41 <li>generate clock and orbit corrections to broadcast ephemeris through an IP port to support real-time Precise Point Positioning on GNSS rovers,</li>42 <li>generate synchronized or unsynchronized clock and orbit corrections to broadcast ephemeris epoch by epoch through an IP port to support the (outside) combination of such streams as coming simultaneously from various correction providers,</li>41 <li>generate clock and orbit corrections to Broadcast Ephemeris through an IP port to support real-time Precise Point Positioning on GNSS rovers,</li> 42 <li>generate synchronized or unsynchronized clock and orbit corrections to Broadcast Ephemeris epoch by epoch through an IP port to support the (outside) combination of such streams as coming simultaneously from various correction providers,</li> 43 43 <li>monitor the performance of a network of real-time GNSS data streams to generate advisory notes in case of outages or corrupted streams,</li> 44 44 <li>scan RTCM streams for incoming antenna information as well as message types and their repetition rates,</li> 45 45 <li>feed a stream into a GNSS receiver via serial communication link,</li> 46 46 <li>carry out a real-time Precise Point Positioning to determine a GNSS rover position,</li> 47 <li>simultaneously process several incoming orbit and clock correction sstreams to produce, encode and upload a combination solution,</li>47 <li>simultaneously process several incoming orbit and clock correction streams to produce, encode and upload a combination solution,</li> 48 48 <li>upload a Broadcast Ephemeris stream in RTCM Version 3 format,</li> 49 49 <li>read GNSS clocks and orbits in a plain ASCII format from an IP port - they can be produced by a real-time GNSS engine such as RTNet and should be referenced to the IGS Earth-Centered-Earth-Fixed (ECEF) reference system and</li> 50 50 <ul> 51 51 <li>convert the IGS Earth-Centered-Earth-Fixed clocks and and orbits into corrections to Broadcast Ephemeris with radial, along-track and cross-track components,</li> 52 <li>upload the clock and orbit corrections as an RTCM Version 3 .xstream to an NTRIP Broadcaster,</li>52 <li>upload the clock and orbit corrections as an RTCM Version 3 stream to an NTRIP Broadcaster,</li> 53 53 <li>refer the clock and orbit corretions to a specific reference system,</li> 54 54 <li>log the Broadcast Ephemeris clock corrections as Clock RINEX files for further processing using other tools than BNC,</li> … … 74 74 75 75 <p> 76 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 pupose 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 satellite orbit and clock correctors. 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 corrections streams to disseminate the combination product while saving results in SP3 and clock RINEX files.76 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 pupose 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 Broadcast Corrections. 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. 77 77 </p> 78 78 <p><img src="IMG/screenshot10.png"/></p> … … 87 87 </p> 88 88 <p><img src="IMG/screenshot02.png"/></p> 89 <p><u>Figure:</u> Flowchart, BNC feeding a real-time GNSS engine and uploading an encoded Broadcast Ephemeris corrections stream.</p>89 <p><u>Figure:</u> Flowchart, BNC feeding a real-time GNSS engine and uploading an encoded Broadcast Corrections stream.</p> 90 90 91 91 <p> 92 92 </p> 93 93 <p><img src="IMG/screenshot19.png"/></p> 94 <p><u>Figure:</u> Flowchart, BNC combining orbit/clock correctorsstreams.</p>94 <p><u>Figure:</u> Flowchart, BNC combining Broadcast Correction streams.</p> 95 95 96 96 … … 110 110 <li>requires access to the Internet with a minimum of about 2 to 6 kbits/sec per stream depending on the stream format and the number of visible satellites. You need to make sure that the connection can sustain the required bandwidth.</li> 111 111 <li>requires the clock of the host computer to be properly synchronized.</li> 112 <li>has the capacity to retrieve hundreds of GNSS data streams simultaneously. Please be aware that such usage may incur a heavy load on the NTRIP broadcaster side depending on the number of streams requested. We recommend limiting the number of streams where possible to avoid unnecessary workload.</li>112 <li>has the capacity to retrieve hundreds of GNSS data streams simultaneously. Please be aware that such usage may incur a heavy load on the NTRIP Broadcaster side depending on the number of streams requested. We recommend limiting the number of streams where possible to avoid unnecessary workload.</li> 113 113 </ul> 114 114 </p> … … 336 336 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> 337 337 <p> 338 Note 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 these are not possible, you might need to run BNC outside your LAN on a host that has unobstructed connection to the Internet.338 Note 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 these are not possible, you might need to run BNC outside your LAN on a host that has unobstructed connection to the Internet. 339 339 </p> 340 340 341 341 <p><a name="ssl"><h4>3.2.2 SSL - Transport Layer Security</h4></p> 342 <p>Communication with an NTRIP broadcaster over SSL requires the exchange of client and/or server certificates. Specify the path to a directory where you save certificates on your system. You may like to check out <u>http://software.rtcm-ntrip.org/wiki/Certificates</u> for a list of known NTRIP server certificates. Don't try communication via SSL if you are not sure wheter this is supported by the involved NTRIP broadcaster. </p>343 <p>SSL communication may involve queries coming from the NTRIP broadcaster. Tick 'Ignore SSL authorization erros' if you don't want to be bothered with this. Note that SSL communication is usually done over port 443.</p>342 <p>Communication with an NTRIP Broadcaster over SSL requires the exchange of client and/or server certificates. Specify the path to a directory where you save certificates on your system. You may like to check out <u>http://software.rtcm-ntrip.org/wiki/Certificates</u> for a list of known NTRIP Server certificates. Don't try communication via SSL if you are not sure wheter this is supported by the involved NTRIP Broadcaster. </p> 343 <p>SSL communication may involve queries coming from the NTRIP Broadcaster. Tick 'Ignore SSL authorization erros' if you don't want to be bothered with this. Note that SSL communication is usually done over port 443.</p> 344 344 345 345 <p><a name="general"><h4>3.3. General</h4></p> … … 350 350 <p><a name="genlog"><h4>3.3.1 Logfile - optional</h4></p> 351 351 <p> 352 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' carrying 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 saved into a file.352 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' carrying 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 saved into a file. 353 353 </p> 354 354 … … 373 373 <p><a name="rawout"><h4>3.3.5 Raw Output File - optional</h4></p> 374 374 <p> 375 BNC can save all data coming in through various streams in one daily file. The information is recorded in the specified 'Raw output file' in the received order and format. This feature allows a BNC user to run the PPP option offline with observations, orbit/clock correctors, and broadcast ephemeris being read from a previously saved file. It supports the offline repetition of a real-time situation for debugging purposes. It is not meant for post-processing.375 BNC can save all data coming in through various streams in one daily file. The information is recorded in the specified 'Raw output file' in the received order and format. This feature allows a BNC user to run the PPP option offline with observations, Broadcast Corrections, and Broadcast Ephemeris being read from a previously saved file. It supports the offline repetition of a real-time situation for debugging purposes. It is not meant for post-processing. 376 376 </p> 377 377 <p> … … 380 380 2010-08-03T18:05:28 RTCM3EPH RTCM_3 67 381 381 </pre> 382 This example block header tells you that 67 bytes were saved in the data block following this time stamp. The information in this block is encoded in RTCM Version 3 .xformat, comes from mountpoint RTCM3EPH and was received at 18:05:29 UTC on 2010-08-03. BNC adds its own time stamps in order to allow the reconstruction of a recorded real-time situation.382 This example block header tells you that 67 bytes were saved in the data block following this time stamp. The information in this block is encoded in RTCM Version 3 format, comes from mountpoint RTCM3EPH and was received at 18:05:29 UTC on 2010-08-03. BNC adds its own time stamps in order to allow the reconstruction of a recorded real-time situation. 383 383 </p> 384 384 <p> … … 388 388 <p><a name="rinex"><h4>3.4. RINEX Observations</h4></p> 389 389 <p> 390 Observations will be converted to RINEX if they come in either RTCM Version 2 .x or RTCM Version 3.xformat. Depending on the RINEX version and incoming RTCM message types, the files generated by BNC may contain data from GPS, GLONASS, Galileo, SBAS, QZSS, and COMPASS. In case an observation type is listed in the RINEX header but the corresponding observation is unavailable, its value is set to zero '0.000'. Note that the 'RINEX TYPE' field in the RINEX Version 3 Observation file header is always set to 'M(MIXED)' or 'Mixed' even if the file only contains data from one system.391 </p> 392 393 <p> 394 The screenshot below shows an example setup of BNC when converting streams to RINEX. Streams are coming from various NTRIP broadcasters as well as from a serial communication link. Specifying a decoder string 'ZERO' would have meant to not convert the affected stream contents but save its contents as received.390 Observations will be converted to RINEX if they come in either RTCM Version 2 or RTCM Version 3 format. Depending on the RINEX version and incoming RTCM message types, the files generated by BNC may contain data from GPS, GLONASS, Galileo, SBAS, QZSS, and COMPASS. In case an observation type is listed in the RINEX header but the corresponding observation is unavailable, its value is set to zero '0.000'. Note that the 'RINEX TYPE' field in the RINEX Version 3 Observation file header is always set to 'M(MIXED)' or 'Mixed' even if the file only contains data from one system. 391 </p> 392 393 <p> 394 The screenshot below shows an example setup of BNC when converting streams to RINEX. Streams are coming from various NTRIP Broadcasters as well as from a serial communication link. Specifying a decoder string 'ZERO' would have meant to not convert the affected stream contents but save its contents as received. 395 395 </p> 396 396 <p><img src="IMG/screenshot16.png"/></p> … … 445 445 <p><a name="rnxskl"><h4>3.4.5 Skeleton Extension - optional</h4></p> 446 446 <p> 447 Whenever BNC starts generating 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 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 v2 header skeleton file for the Brussels EPN station.447 Whenever BNC starts generating 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 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 Version 2 header skeleton file for the Brussels EPN station. 448 448 </p> 449 449 <p> … … 467 467 <li>Personal skeletons should contain a complete first header record of type 468 468 <br>- RINEX VERSION / TYPE<br> 469 Note the small differences mentioned below with regards to RINEX v2 and RINEX v2 skeletons.</li>469 Note the small differences mentioned below with regards to RINEX Version 2 and RINEX Version 2 skeletons.</li> 470 470 <li>They should then contain an empty header record of type 471 471 <br>- PGM / RUN BY / DATE<br> … … 478 478 <br>- APPROX POSITION XYZ 479 479 <br>- ANTENNA: DELTA H/E/N 480 <br>- WAVELENGTH FACT L1/2 (RINEX v2)</li>480 <br>- WAVELENGTH FACT L1/2 (RINEX Version 2)</li> 481 481 <li>They may contain any other optional complete header record as defined in the RINEX documentation.</li> 482 482 <li>They should then contain empty header records of type 483 <br>- # / TYPES OF OBSERV (RINEX v2)484 <br>- SYS/ # / OBS TYPES (RINEX v3)483 <br>- # / TYPES OF OBSERV (RINEX Version 2) 484 <br>- SYS/ # / OBS TYPES (RINEX Version 3) 485 485 <br>- TIME OF FIRST OBS 486 486 <br>BNC will include these lines in the final RINEX file header together with an additional … … 512 512 <p><a name="ephemeris"><h4>3.5. RINEX Ephemeris</h4></p> 513 513 <p> 514 Broadcast ephemeris can be saved as RINEX Navigation files when received via RTCM Version 3 .xe.g. as message types 1019 (GPS) or 1020 (GLONASS) or 1045 (Galileo). The file name convention follows the details given in section 'RINEX File Names' except that the first four characters are 'BRDC' and the last character is514 Broadcast ephemeris can be saved as RINEX Navigation files when received via RTCM Version 3 e.g. as message types 1019 (GPS) or 1020 (GLONASS) or 1045 (Galileo). The file name convention follows the details given in section 'RINEX File Names' except that the first four characters are 'BRDC' and the last character is 515 515 </p> 516 516 <ul> … … 520 520 521 521 <p> 522 Note that streams dedicated to carry Broadacst Ephemeris messages in RTCM v3 format in high repetition rates are listed on <u>http://igs.bkg.bund.de/ntrip/ephemeris</u>.522 Note that streams dedicated to carry Broadacst Ephemeris messages in RTCM Version 3 format in high repetition rates are listed on <u>http://igs.bkg.bund.de/ntrip/ephemeris</u>. 523 523 </p> 524 524 525 525 <p><a name="ephdir"><h4>3.5.1 Directory - optional</h4></p> 526 526 <p> 527 Specify a path for saving broadcast ephemeris data as RINEX Navigation files. If the specified directory does not exist, BNC will not create RINEX Navigation files. Default value for Ephemeris 'Directory' is an empty option field, meaning that no RINEX Navigation files will be created.527 Specify a path for saving Broadcast Ephemeris data as RINEX Navigation files. If the specified directory does not exist, BNC will not create RINEX Navigation files. Default value for Ephemeris 'Directory' is an empty option field, meaning that no RINEX Navigation files will be created. 528 528 </p> 529 529 … … 535 535 <p><a name="ephport"><h4>3.5.3 Port - optional</h4></p> 536 536 <p> 537 BNC can output broadcast ephemeris in RINEX Version 3 format on your local host (IP 127.0.0.1) through an IP 'Port'. Specify an IP port number to activate this function. The default is an empty option field, meaning that no ASCII ephemeris output via IP port is generated.537 BNC can output Broadcast Ephemeris in RINEX Version 3 format on your local host (IP 127.0.0.1) through an IP 'Port'. Specify an IP port number to activate this function. The default is an empty option field, meaning that no ASCII ephemeris output via IP port is generated. 538 538 </p> 539 539 <p> … … 543 543 <p><a name="ephvers"><h4>3.5.4 Version - optional</h4></p> 544 544 <p> 545 Default format for RINEX Navigation files containing broadcast ephemeris is RINEX Version 2.11. Select 'Version 3' if you want to save the ephemeris in RINEX Version 3 format.546 </p> 547 <p> 548 Note that this does not concern the broadcast ephemeris output through IP port which is always in RINEX Version 3 format.545 Default format for RINEX Navigation files containing Broadcast Ephemeris is RINEX Version 2.11. Select 'Version 3' if you want to save the ephemeris in RINEX Version 3 format. 546 </p> 547 <p> 548 Note that this does not concern the Broadcast Ephemeris output through IP port which is always in RINEX Version 3 format. 549 549 </p> 550 550 … … 571 571 </p> 572 572 <p> 573 When converting RINEX version2 to RINEX version 3, the tracking mode or channel information in the (last character out of the three character) observation code is left blank if unknown. When converting RINEX version 3 to RINEX version 2574 <ul> 575 <li>C1P in RINEX version 3 is mapped to P1 in RINEX version 2</li>576 <li>C2P in RINEX version 3 is mapped to P2 in RINEX version 2</li>577 <li>If several observations in RINEX version 3 come with the same observation type, same band/frequency but different tracking modes, BNC uses only the one provided first for creating RINEX version 2 while ignoring the others.</li>573 When converting RINEX Version 2 to RINEX Version 3, the tracking mode or channel information in the (last character out of the three character) observation code is left blank if unknown. When converting RINEX Version 3 to RINEX Version 2 574 <ul> 575 <li>C1P in RINEX Version 3 is mapped to P1 in RINEX Version 2</li> 576 <li>C2P in RINEX Version 3 is mapped to P2 in RINEX Version 2</li> 577 <li>If several observations in RINEX Version 3 come with the same observation type, same band/frequency but different tracking modes, BNC uses only the one provided first for creating RINEX Version 2 while ignoring the others.</li> 578 578 </ul> 579 579 </p> … … 653 653 </p> 654 654 <p> 655 The first five parameters in each broadcast corrections record are:656 </p> 657 <p> 658 <ul> 659 <li>RTCM v3 message type number</li>655 The first five parameters in each Broadcast Corrections record are: 656 </p> 657 <p> 658 <ul> 659 <li>RTCM Version 3 message type number</li> 660 660 <li>SSR message update interval indicator</li> 661 661 <ul> … … 898 898 899 899 <p> 900 The following figure shows the screenshot of a BNC configuration where a number of streams is pulled from different NTRIP broadcasters to feed a GNSS engine via IP port output.900 The following figure shows the screenshot of a BNC configuration where a number of streams is pulled from different NTRIP Broadcasters to feed a GNSS engine via IP port output. 901 901 </p> 902 902 <p><img src="IMG/screenshot12.png"/></p> … … 936 936 <p><a name="serial"><h4>3.9. Serial Output</h4></p> 937 937 <p> 938 You may use BNC to feed a serial connected device like an GNSS receiver. For that an incoming streams can be forwarded to a serial port. 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 rover.938 You may use BNC to feed a serial connected device like an GNSS receiver. For that an incoming streams can be forwarded to a serial port. 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 rover. 939 939 </p> 940 940 <p><img src="IMG/screenshot11.png"/></p> … … 993 993 <p><a name="serauto"><h4>3.9.8 NMEA - mandatory for VRS streams</h4></p> 994 994 <p> 995 Select 'Auto' to automatically forward all NMEA-GGA messages coming from your serial connected GNSS receiver to the NTRIP broadcaster and/or save them in a file.996 </p> 997 <p> 998 Forwarding valid NMEA-GGA messages to the NTRIP broadcaster is required for receiving 'Virtual Reference Station' (VRS) streams. Thus, in case your serial connected receiver is not capable to provide them, the alternative for VRS streams is a 'Manual' simulation of an initial NMEA-GGA message. Its contents is based on the approximate (editable) latitude/longitude from the broadcaster's source-table and an approximate VRS height to be specified.995 Select 'Auto' to automatically forward all NMEA-GGA messages coming from your serial connected GNSS receiver to the NTRIP Broadcaster and/or save them in a file. 996 </p> 997 <p> 998 Forwarding valid NMEA-GGA messages to the NTRIP Broadcaster is required for receiving 'Virtual Reference Station' (VRS) streams. Thus, in case your serial connected receiver is not capable to provide them, the alternative for VRS streams is a 'Manual' simulation of an initial NMEA-GGA message. Its contents is based on the approximate (editable) latitude/longitude from the broadcaster's source-table and an approximate VRS height to be specified. 999 999 </p> 1000 1000 <p> … … 1125 1125 <p><a name="miscscan"><h4>3.11.3 Scan RTCM - optional</h4></p> 1126 1126 <p> 1127 When configuring a GNSS receiver for RTCM stream generation, the firmware's setup interface may not provide details about RTCM message types. As reliable information concerning stream contents should be available i.e. for NTRIP broadcaster operators to maintain the broadcaster's source-table, BNC allows to scan RTCM streams for incoming message types and printout some of the contained meta-data. The idea for this option arose from 'InspectRTCM', a comprehensive stream analyzing tool written by D. Stoecker.1128 </p> 1129 <p> 1130 Tick 'Scan RTCM' to scan RTCM Version 2 .x or 3.xstreams and log all contained1127 When configuring a GNSS receiver for RTCM stream generation, the firmware's setup interface may not provide details about RTCM message types. As reliable information concerning stream contents should be available i.e. for NTRIP Broadcaster operators to maintain the broadcaster's source-table, BNC allows to scan RTCM streams for incoming message types and printout some of the contained meta-data. The idea for this option arose from 'InspectRTCM', a comprehensive stream analyzing tool written by D. Stoecker. 1128 </p> 1129 <p> 1130 Tick 'Scan RTCM' to scan RTCM Version 2 or 3 streams and log all contained 1131 1131 </p> 1132 1132 <ul> … … 1140 1140 1141 1141 <p> 1142 Note that in RTCM Version 2 .xthe message types 18 and 19 carry only the observables of one frequency. Hence it needs two type 18 and 19 messages per epoch to transport the observations from dual frequency receivers.1142 Note that in RTCM Version 2 the message types 18 and 19 carry only the observables of one frequency. Hence it needs two type 18 and 19 messages per epoch to transport the observations from dual frequency receivers. 1143 1143 </p> 1144 1144 <p> … … 1153 1153 BNC can derive coordinates for a rover position following the Precise Point Positioning (PPP) approach. It uses either code or code plus phase data in ionosphere free linear combinations P3 or L3. Besides pulling a stream of observations from a dual frequency receiver, this also 1154 1154 <ul> 1155 <li>requires pulling in addition a stream carrying satellite orbit and clock corrections to Broadcast Ephemeris in the form of RTCM v3 'State Space Representation' (SSR) messages. Note that for BNC these correctors need to be referred to the satellite's Antenna Phase Center (APC). Streams providing such messages are listed on <u>http://igs.bkg.bund.de/ntrip/orbits</u>. Stream 'CLK11' on NTRIP broadcaster 'products.igs-ip.net:2101' is an example.</li>1155 <li>requires pulling in addition a stream carrying satellite orbit and clock corrections to Broadcast Ephemeris in the form of RTCM Version 3 'State Space Representation' (SSR) messages. Note that for BNC these Broadcast Corrections need to be referred to the satellite's Antenna Phase Center (APC). Streams providing such messages are listed on <u>http://igs.bkg.bund.de/ntrip/orbits</u>. Stream 'CLK11' on NTRIP Broadcaster 'products.igs-ip.net:2101' is an example.</li> 1156 1156 <li>may require pulling a stream carrying Broadcast Ephemeris available as RTCM Version 3 message types 1019, 1020, and 1045. This is a must only when the stream coming from the receiver does not contain Broadcast Ephemeris or provides them only at very low repetition rate. Streams providing such messages are listed on <u>http://igs.bkg.bund.de/ntrip/ephemeris</u>. Stream 'RTCM3EPH' on caster 'products.igs-ip.net:2101' is an example.</li> 1157 1157 </ul> … … 1246 1246 1247 1247 <p> 1248 Note that BNC's 'PPP Client' option can also be used offline for debugging purposes. Apply the 'File Mode' command line options for that to read a file containing synchronized observations, orbit and clock corretors, and broadcast ephemeris. Such a file must be generated using BNC's 'Raw output file' option. Example:1248 Note that BNC's 'PPP Client' option can also be used offline for debugging purposes. Apply the 'File Mode' command line options for that to read a file containing synchronized observations, orbit and clock corretors, and Broadcast Ephemeris. Such a file must be generated using BNC's 'Raw output file' option. Example: 1249 1249 </p> 1250 1250 … … 1257 1257 <ul> 1258 1258 <li>BNC does correct for Solid Earth Tides and Phase Windup.</li> 1259 <li>Satellite Antenna Phase Center Offsets are not corrected because applied orbit/clock correct ors are referred to the satellite's antenna phase center.</li>1259 <li>Satellite Antenna Phase Center Offsets are not corrected because applied orbit/clock corrections are referred to the satellite's antenna phase center.</li> 1260 1260 <li>Satellite Antenna Phase Center Variations are neglected because this is a small effect usually less than 2 centimeters.</li> 1261 1261 <li>Observations can be corrected for a Receiver Antenna Offset. Depending on whether or not this correction is applied, the estimated position is either that of the receiver's antenna phase center or that of the receiver's Antenna Reference Point.</li> … … 1268 1268 <p><a name="pppmode"><h4>3.12.1 Mode & Mountpoints - optional</h4></p> 1269 1269 <p> 1270 Specify the Point Positioning mode you want to apply and the mountpoints for observations and Broadcast Ephemeris corrections.1270 Specify the Point Positioning mode you want to apply and the mountpoints for observations and Broadcast Corrections. 1271 1271 </p> 1272 1272 … … 1340 1340 1341 1341 <p><a name="ppppost"><h4>3.12.5 Post Processing - optional</h4></p> 1342 <p>When in 'Post-Processing mode<ul><li>specifying a RINEX Observation, a RINEX Navigation and a Broadcast Ephemeris corrections file leads to a PPP solution.</li><li>specifying only a RINEX Observation and a RINEX Navigation file and no Broadcast Ephemeris corrections file leads to a SPP solution.</ul></p>1343 <p>BNC accepts RINEX v2 as well as RINEX v3 observation or navigation file formats. Files carrying Broadcast Ephemeris corrections must have the format produced by BNC in the 'Broadcast Corrections' tab.1342 <p>When in 'Post-Processing mode<ul><li>specifying a RINEX Observation, a RINEX Navigation and a Broadcast Corrections file leads to a PPP solution.</li><li>specifying only a RINEX Observation and a RINEX Navigation file and no Broadcast Corrections file leads to a SPP solution.</ul></p> 1343 <p>BNC accepts RINEX Version 2 as well as RINEX Version 3 observation or navigation file formats. Files carrying Broadcast Corrections must have the format produced by BNC in the 'Broadcast Corrections' tab. 1344 1344 <p> 1345 1345 Post Processing PPP results can be saved in a specific output file. … … 1505 1505 <p><a name="combi"><h4>3.13. Combination</h4></p> 1506 1506 <p> 1507 BNC allows to process several orbit and clock corrections streams in real-time to produce, encode, upload and save a combination of correctors from various providers. It is so far only the satellite clock corrections which are combined while orbit correctors in the combination product as well as the product update rates are just taken over from one of the incoming Broadcast Ephemeris 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.1507 BNC allows to process several orbit and clock corrections 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. 1508 1508 </p> 1509 1509 <p> … … 1517 1517 In view of IGS real-time products, the 'Combination' functionality has been integrated in BNC because 1518 1518 <ul> 1519 <li>the software with its Graphic User Interface and wide range of supported Operation Systems represents a perfect platform to process many broadcast correctionsstreams in parallel;</li>1519 <li>the software with its Graphic User Interface and wide range of supported Operation Systems represents a perfect platform to process many Broadcast Correction streams in parallel;</li> 1520 1520 <li>outages of single AC product streams can be mitigated through merging several incoming streams into a combined product;</li> 1521 1521 <li>generating a combination product from several AC products allows detecting and rejecting outliers;</li> … … 1558 1558 </p> 1559 1559 <p> 1560 Note that BNC can produce an internal PPP solution from combined Broadcast Ephemeris corrections. For that you have to specify the keyword 'INTERNAL' as 'Corrections Mounpoint' in the PPP (1) panel.1561 </p> 1562 <p> 1563 Note further that the combination procedure in BNC also - formally - works with only one Broadcast Ephemeris corrections stream specified for combination.1560 Note that BNC can produce an internal PPP solution from combined Broadcast Corrections. For that you have to specify the keyword 'INTERNAL' as 'Corrections Mounpoint' in the PPP (1) panel. 1561 </p> 1562 <p> 1563 Note further that the combination procedure in BNC also - formally - works with only one Broadcast Corrections stream specified for combination. 1564 1564 </p> 1565 1565 <p> … … 1569 1569 <p><a name="combimounttab"><h4>3.13.1 Combination Table - optional</h4></p> 1570 1570 <p> 1571 Hit the 'Add Row' button, double click on the 'Mountpoint' field, enter a Broadcast Ephemeris corrections mountpoint from the 'Streams' section and hit Enter. Then double click on the 'AC Name' field to enter your choice of an abbreviation for the Analysis Center (AC) providing the stream. Finally, double click on the 'Weight' field to enter a weight to be applied to this stream in the combination. The stream processing can already be startet whith only one corrections stream configured for combination.1571 Hit the 'Add Row' button, double click on the 'Mountpoint' field, enter a Broadcast Corrections mountpoint from the 'Streams' section and hit Enter. Then double click on the 'AC Name' field to enter your choice of an abbreviation for the Analysis Center (AC) providing the stream. Finally, double click on the 'Weight' field to enter a weight to be applied to this stream in the combination. The stream processing can already be startet whith only one corrections stream configured for combination. 1572 1572 </p> 1573 1573 <p> … … 1586 1586 1587 1587 <p> 1588 The following screenshots describe an example setup of BNC when combining orbit and clock correctors streams and upload them to an NTRIP broadcaster. Note that it requires to specify options under tabs 'Combination' and 'Upload (clk)'. The example uses the combination product to simultaneously carry out an 'INTERNAL' PPP solution in Quickstart mode which allows to monitor the quality of the combination product in the space domain.1588 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 to specify options under tabs 'Combination' and 'Upload (clk)'. The example uses the combination product to simultaneously carry out an 'INTERNAL' PPP solution in Quickstart mode which allows to monitor the quality of the combination product in the space domain. 1589 1589 </p> 1590 1590 1591 1591 <br> 1592 1592 <p><img src="IMG/screenshot20.png"/></p> 1593 <p><u>Figure:</u> BNC combining orbit/clock correctorsstreams.</p>1593 <p><u>Figure:</u> BNC combining Broadcast Correction streams.</p> 1594 1594 <p></p> 1595 1595 <p><img src="IMG/screenshot21.png"/></p> 1596 <p><u>Figure:</u> BNC uploading the combined orbit/clock correctors stream.</p>1596 <p><u>Figure:</u> BNC uploading the combined Broadcast Corrections stream.</p> 1597 1597 <p></p> 1598 1598 <p><img src="IMG/screenshot23.png"/></p> 1599 <p><u>Figure:</u> 'INTERNAL' PPP with BNC using combined orbit/clock correctors stream.</p>1599 <p><u>Figure:</u> 'INTERNAL' PPP with BNC using combined Broadcast Corrections stream.</p> 1600 1600 1601 1601 <p><a name="combimethod"><h4>3.13.1.2 Method - mandatory if 'Combination Table' is populated</h4></p> 1602 1602 <p> 1603 Selecet 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 Ephemeris corrections is intended for Precise Point Positioning support.1603 Selecet 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. 1604 1604 </p> 1605 1605 … … 1614 1614 BNC can upload streams carrying orbit and clock corrections to Broadcast Ephemeris in radial, along-track and cross-track components if they are<ol type=a> 1615 1615 <li> 1616 either generated by BNC as a combination of several individual correctorsstreams coming from an number of real-time Analysis Centers (ACs), see section 'Combination',</li>1616 either generated by BNC as a combination of several individual Boradcast Correction streams coming from an number of real-time Analysis Centers (ACs), see section 'Combination',</li> 1617 1617 <li> 1618 or generated by BNC because the program receives an ASCII stream of 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>1618 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> 1619 1619 </ol> 1620 1620 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: … … 1629 1629 <li>Tranform these differences into radial, along-track and cross-track corrections to Broadcast Ephemeris orbits. </li> 1630 1630 <li>Calculate corrections to Broadcast Ephemeris clocks as differences between Broadcast Ephemeris and IGS08 clocks. </li> 1631 <li>Encode Broadcast Ephemeris clock and orbit corrections in RTCM Version 3 .xformat. </li>1631 <li>Encode Broadcast Ephemeris clock and orbit corrections in RTCM Version 3 format. </li> 1632 1632 <li>Upload corrections stream to NTRIP Broadcaster. </li> 1633 1633 </ul> … … 1635 1635 </p> 1636 1636 <p> 1637 The usual handling of BNC when uploading a stream with orbit and clock correctors is that you first specify Broadcast Ephemeris and Broadcast Ephemeris correction streams. You then specify an NTRIP broadcaster for stream upload before you start the program.1638 </p> 1639 <p> 1640 BNC requires GNSS clocks and orbits in the IGS Earth-Centered-Earth-Fixed (ECEF) reference system and in a specific ASCII format. The clocks and orbits must be referred to satellite Center of Mass (CoM) and must not containing the conventional periodic relativistic effect. They may be provided by a real-time GNSS engine such as RTNet. The sampling rate for data transmission should not exceed 15 sec. Note that otherwise tools involved in IP streaming such as NTRIP Broadcasters or NTRIP clients may respond with a timeout.1637 The usual handling of BNC when uploading a stream with Broadcast Corrections is that you first specify Broadcast Ephemeris and Broadcast Correction streams. You then specify an NTRIP Broadcaster for stream upload before you start the program. 1638 </p> 1639 <p> 1640 BNC requires GNSS clocks and orbits in the IGS Earth-Centered-Earth-Fixed (ECEF) reference system and in a specific ASCII format. The clocks and orbits must be referred to satellite Center of Mass (CoM) and must not containing the conventional periodic relativistic effect. They may be provided by a real-time GNSS engine such as RTNet. The sampling rate for data transmission should not exceed 15 sec. Note that otherwise tools involved in IP streaming such as NTRIP Broadcasters or NTRIP Clients may respond with a timeout. 1641 1641 </p> 1642 1642 … … 1702 1702 <p><a name="uphost"><h4>3.14.2 Host, Port, Mountpoint, Password - mandatory if 'Upload Table' entries specified</h4></p> 1703 1703 1704 <p>Specify the domain name or IP number of an NTRIP Broadcaster for uploading the stream. Furthermore, specify the caster's listening IP port, an upload mountpoint and an upload password. Note that NTRIP Casters are often configured to provide access on more than one port, usually port 80 and 2101. If you experience communication problems on port 80, you should try to use the alternative port(s).1704 <p>Specify the domain name or IP number of an NTRIP Broadcaster for uploading the stream. Furthermore, specify the caster's listening IP port, an upload mountpoint and an upload password. Note that NTRIP Broadcasters are often configured to provide access on more than one port, usually port 80 and 2101. If you experience communication problems on port 80, you should try to use the alternative port(s). 1705 1705 </p> 1706 1706 <p> … … 1713 1713 <p><a name="upsystem"><h4>3.14.3 System - mandatory if 'Host' is set</h4></p> 1714 1714 <p> 1715 BNC allows to configure several Broadcast Ephemeris correction streams for upload so that they refere to different reference systems and different NTRIP broadcasters. You may use this functionality for parallel support of a backup NTRIP broadcaster or for simultaneous support of several reference systems. Available options for referring clock and orbit corrections to specific target reference systems are1715 BNC allows to configure several Broadcast Correction streams for upload so that they refere to different reference systems and different NTRIP Broadcasters. You may use this functionality for parallel support of a backup NTRIP Broadcaster or for simultaneous support of several reference systems. Available options for referring clock and orbit corrections to specific target reference systems are 1716 1716 <p> 1717 1717 <ul> … … 1727 1727 1728 1728 <p> 1729 BNC only transforms the original IGS08 <u>orbits</u> in the Broadcast Ephemeris corrections stream to a target reference system while leaving the clocks unchanged. From a theoretical point of view this leads to inconsistencies between orbits and clocks and is therefore not allowed. However, it has been shown by L.Huisman et al. 2012 that as long as involved scale parameters are small enough, this way of transforming corrections stream contents only leads to hight biases less than about one centimeter. With regards to the systems listed above, the approach has therefore been implemented in BNC for practical reasons.1729 BNC only transforms the original IGS08 <u>orbits</u> in the Broadcast Corrections stream to a target reference system while leaving the clocks unchanged. From a theoretical point of view this leads to inconsistencies between orbits and clocks and is therefore not allowed. However, it has been shown by Huisman et al. 2012 that as long as involved scale parameters are small enough, this way of transforming corrections stream contents only leads to hight biases less than about one centimeter. With regards to the systems listed above, the approach has therefore been implemented in BNC for practical reasons. 1730 1730 </p> 1731 1731 <p> … … 1858 1858 <p><a name="upcom"><h4>3.14.4 Center of Mass - optional</h4></p> 1859 1859 <p> 1860 BNC allows to either refer orbit/clock corrections to the satellite's Center of Mass (CoM) or to the satellite's Antenna Phase Center (APC). By default corrections refer to APC. Tick 'Center of Mass' to refer uploaded corrections to CoM.1860 BNC allows to either refer Broadcast Corrections to the satellite's Center of Mass (CoM) or to the satellite's Antenna Phase Center (APC). By default corrections refer to APC. Tick 'Center of Mass' to refer uploaded corrections to CoM. 1861 1861 </p> 1862 1862 … … 1867 1867 </p> 1868 1868 <p> 1869 As an SP3 file contents should be referred to the satellites Center of Mass (CoM) while correctors are referred to the satellites Antenna Phase Center (APC), an offset has to be applied which is available from an IGS ANTEX file (see section 'ANTEX File'). You should therefore specify the 'ANTEX File' path under tab 'PPP (2)' if you want to save the stream contents in SP3 format. If you don't specify an 'ANTEX File' path there, the SP3 file contents will be referred to the satellites APCs.1869 As an SP3 file contents should be referred to the satellites Center of Mass (CoM) while Broadcast Corrections are referred to the satellites Antenna Phase Center (APC), an offset has to be applied which is available from an IGS ANTEX file (see section 'ANTEX File'). You should therefore specify the 'ANTEX File' path under tab 'PPP (2)' if you want to save the stream contents in SP3 format. If you don't specify an 'ANTEX File' path there, the SP3 file contents will be referred to the satellites APCs. 1870 1870 </p> 1871 1871 <p> … … 1899 1899 1900 1900 <p> 1901 The following screenshot shows the encoding and uploading of a stream of precise orbits and clocks coming form a real-time engine in 'RTNET' ASCII format. The stream is uploaded to NTRIP broadcaster 'products.igs-ip.net'. It is referred to APC and IGS08. Uploaded data are locally saved in SP3 and clock RINEX format. Required Broadcast Ephemeris are received via stream 'RTCM3EPH'.1901 The following screenshot shows the encoding and uploading of a stream of precise orbits and clocks coming form a real-time engine in 'RTNET' ASCII format. The stream is uploaded to NTRIP Broadcaster 'products.igs-ip.net'. It is referred to APC and IGS08. Uploaded data are locally saved in SP3 and Clock RINEX format. Required Broadcast Ephemeris are received via stream 'RTCM3EPH'. 1902 1902 </p> 1903 1903 <p><img src="IMG/screenshot26.png"/></p> 1904 <p><u>Figure:</u> Producing Broadcast Corrections from incoming precise orbits and clocks and uploading them to an NTRIP broadcaster.</p>1904 <p><u>Figure:</u> Producing Broadcast Corrections from incoming precise orbits and clocks and uploading them to an NTRIP Broadcaster.</p> 1905 1905 1906 1906 <p><a name="upeph"><h4>3.15. Upload (eph) </h4></p> 1907 1907 <p> 1908 BNC can upload a stream carrying Broadcast Ephemeris in RTCM Version 3 format to an NTRIP Caster.1908 BNC can upload a stream carrying Broadcast Ephemeris in RTCM Version 3 format to an NTRIP Broadcaster. 1909 1909 </p> 1910 1910 … … 1914 1914 </p> 1915 1915 <p> 1916 Enter the NTRIP Caster's IP 'Port' number for stream upload. Note that NTRIP Casters are often configured to provide access on more than one port, usually1916 Enter the NTRIP Broadcaster's IP 'Port' number for stream upload. Note that NTRIP Broadcasters are often configured to provide access on more than one port, usually 1917 1917 port 80 and 2101. If you experience communication problems on port 80, you should try to use the alternative port(s). 1918 1918 </p> … … 1930 1930 <p><a name="streams"><h4>3.16. Streams</h4></p> 1931 1931 <p> 1932 Each stream on an NTRIP broadcaster (and consequently on BNC) is defined using a unique source ID called mountpoint. An NTRIP client like BNC access the desired data stream by referring to its mountpoint. Information about streams and their mountpoints is available through the source-table maintained by the NTRIP broadcaster. Note that mountpoints could show up in BNC more than once when retrieving streams from several NTRIP broadcasters.1933 </p> 1934 1935 <p> 1936 Streams selected for retrieval are listed under the 'Streams' canvas section on BNC's main window. The list provides the following information either extracted from source-table(s) produced by the NTRIP broadcasters or introduced by BNC's user:1932 Each stream on an NTRIP Broadcaster (and consequently on BNC) is defined using a unique source ID called mountpoint. An NTRIP Client like BNC access the desired data stream by referring to its mountpoint. Information about streams and their mountpoints is available through the source-table maintained by the NTRIP Broadcaster. Note that mountpoints could show up in BNC more than once when retrieving streams from several NTRIP Broadcasters. 1933 </p> 1934 1935 <p> 1936 Streams selected for retrieval are listed under the 'Streams' canvas section on BNC's main window. The list provides the following information either extracted from source-table(s) produced by the NTRIP Broadcasters or introduced by BNC's user: 1937 1937 </p> 1938 1938 <p> 1939 1939 <table> 1940 <tr><td>'resource loader' </td><td>NTRIP broadcaster URL and port, or<br>TCP/IP host and port, or<br>UDP port, or<br>Serial input port specification.</td></tr>1941 <tr><td>'mountpoint' </td><td>Mountpoint introduced by NTRIP broadcaster, or<br>Mountpoint introduced by BNC's user.</td></tr>1940 <tr><td>'resource loader' </td><td>NTRIP Broadcaster URL and port, or<br>TCP/IP host and port, or<br>UDP port, or<br>Serial input port specification.</td></tr> 1941 <tr><td>'mountpoint' </td><td>Mountpoint introduced by NTRIP Broadcaster, or<br>Mountpoint introduced by BNC's user.</td></tr> 1942 1942 <tr><td>'decoder' </td><td>Name of decoder used to handle the incoming stream content according to its format; editable.</td></tr> 1943 1943 <tr><td>'lat' </td><td>Approximate latitude of reference station, in degrees, north; editable if 'nmea' = 'yes'.</td></tr> … … 1958 1958 </li> 1959 1959 <li> 1960 BNC 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 a 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 messages.1960 BNC 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 a 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 messages. 1961 1961 <br>If NMEA-GGA messages 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 most 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. 1962 1962 <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.. … … 1997 1997 <p><a name="latency"><h4>3.17.3 Latency</h4></p> 1998 1998 <p> 1999 The latency of observations in each incoming stream is shown in the 'Latency' tab in milliseconds or seconds. Streams not carrying observations (i.e. those providing only broadcast ephemeris messages) or having an outage are not considered here and shown in red color. Note that the calculation of correct latencies requires the clock of the host computer to be properly synchronized. The next figure shows the latency of incoming streams.1999 The latency of observations in each incoming stream is shown in the 'Latency' tab in milliseconds or seconds. Streams not carrying observations (i.e. those providing only Broadcast Ephemeris messages) or having an outage are not considered here and shown in red color. Note that the calculation of correct latencies requires the clock of the host computer to be properly synchronized. The next figure shows the latency of incoming streams. 2000 2000 </p> 2001 2001 … … 2022 2022 2023 2023 <p> 2024 Button 'Add Stream' > 'Coming from Caster' then opens a window that allows user to select data streams from an NTRIP broadcaster according to their mountpoints and show a distribution map of offered streams.2024 Button 'Add Stream' > 'Coming from Caster' then opens a window that allows user to select data streams from an NTRIP Broadcaster according to their mountpoints and show a distribution map of offered streams. 2025 2025 </p> 2026 2026 2027 2027 <p><a name="streamhost"><h4>3.18.1.1 Caster Host and Port - mandatory</h4></p> 2028 2028 <p> 2029 Enter the NTRIP broadcaster host IP and port number. Note that EUREF and IGS operate NTRIP broadcasters at <u>http://www.euref-ip.net/home</u> and <u>http://www.igs-ip.net/home</u> and <u>http://www.products.igs-ip.net/home</u>.2029 Enter the NTRIP Broadcaster host IP and port number. Note that EUREF and IGS operate NTRIP Broadcasters at <u>http://www.euref-ip.net/home</u> and <u>http://www.igs-ip.net/home</u> and <u>http://www.products.igs-ip.net/home</u>. 2030 2030 </p> 2031 2031 2032 2032 <p><a name="streamtable"><h4>3.18.1.2 Casters Table - optional</h4></p> 2033 2033 <p> 2034 It may be that your are not sure about your NTRIP broadcasters host and port number or you are interested in other broadcaster installations operated elsewhere. Hit 'Show' for a table of known broadcasters maintained at <u>www.rtcm-ntrip.org/home</u>. A window opens which allows to select a broadcaster for stream retrieval, see figure below.2034 It may be that your are not sure about your NTRIP Broadcasters host and port number or you are interested in other broadcaster installations operated elsewhere. Hit 'Show' for a table of known broadcasters maintained at <u>www.rtcm-ntrip.org/home</u>. A window opens which allows to select a broadcaster for stream retrieval, see figure below. 2035 2035 </p> 2036 2036 </p> … … 2041 2041 <p><a name="streamuser"><h4>3.18.1.3 User and Password - mandatory for protected streams</h4></p> 2042 2042 <p> 2043 Some streams on NTRIP broadcasters may be restricted. Enter a valid 'User' ID and 'Password' for access to protected streams. Accounts are usually provided per NTRIP broadcaster through a registration procedure. Register through <u>http://igs.bkg.bund.de/ntrip/registeruser</u> for access to protected streams on <u>www.euref-ip.net</u> or <u>www.igs-ip.net</u> or <u>products.igs-ip.net</u>.2043 Some streams on NTRIP Broadcasters may be restricted. Enter a valid 'User' ID and 'Password' for access to protected streams. Accounts are usually provided per NTRIP Broadcaster through a registration procedure. Register through <u>http://igs.bkg.bund.de/ntrip/registeruser</u> for access to protected streams on <u>www.euref-ip.net</u> or <u>www.igs-ip.net</u> or <u>products.igs-ip.net</u>. 2044 2044 </p> 2045 2045 2046 2046 <p><a name="gettable"><h4>3.18.1.4 Get Table</h4></p> 2047 2047 <p> 2048 Use the 'Get Table' button to download the source-table from the NTRIP broadcaster. Pay attention to data fields 'format' and 'format-details'. Keep in mind that BNC can only decode and convert streams that come in RTCM Version 2.x, RTCM Version 3.x, or RTNET format. For access to observations, ephemeris or ephemris correctiors, an RTCM Version 2.x streams must contain message types 18 and 19 or 20 and 21 while an RTCM Version 3.xstreams must contain2048 Use the 'Get Table' button to download the source-table from the NTRIP Broadcaster. Pay attention to data fields 'format' and 'format-details'. Keep in mind that BNC can only decode and convert streams that come in RTCM Version 2, RTCM Version 3, or RTNET format. For access to observations, ephemeris or ephemris correctiors, an RTCM Version 2 streams must contain message types 18 and 19 or 20 and 21 while an RTCM Version 3 streams must contain 2049 2049 <ul> 2050 2050 <li>GPS or SBAS message types 1002 or 1004, or</li> … … 2053 2053 <li>proposed 'Multiple Signal Messages' (MSM) for GPS, GLONASS, or Galileo, types 1071-1077, 1081-1087, or 1091-1097.</li> 2054 2054 </ul> 2055 see data field 'format-details' for available message types and their repetition rates in brackets. Note that in order to produce RINEX Navigation files RTCM Version 3 .xstreams containing message types 1019 (GPS) and 1020 (GLONASS) and 1045 (Galileo) are required. Select your streams line by line, use +Shift and +Ctrl when necessary. The figure below provides an example source-table.2055 see data field 'format-details' for available message types and their repetition rates in brackets. Note that in order to produce RINEX Navigation files RTCM Version 3 streams containing message types 1019 (GPS) and 1020 (GLONASS) and 1045 (Galileo) are required. Select your streams line by line, use +Shift and +Ctrl when necessary. The figure below provides an example source-table. 2056 2056 </p> 2057 2057 <p> … … 2068 2068 </p> 2069 2069 <p><img src="IMG/screenshot24.png"/></p> 2070 <p><u>Figure:</u> Stream distribution map derived from NTRIP Caster source-table.</p>2070 <p><u>Figure:</u> Stream distribution map derived from NTRIP Broadcaster source-table.</p> 2071 2071 2072 2072 <p><a name="ntripv"><h4>3.18.1.5 NTRIP Version - mandatory</h4></p> … … 2260 2260 </li> 2261 2261 <li> 2262 Using RTCM Version 3 .xto produce RINEX files, BNC will properly handle most message types. However, when handling message types 1001, 1003, 1009 and 1011 where the ambiguity field is not set, the output will be no valid RINEX. All values will be stored modulo 299792.458 (speed of light).2262 Using RTCM Version 3 to produce RINEX files, BNC will properly handle most message types. However, when handling message types 1001, 1003, 1009 and 1011 where the ambiguity field is not set, the output will be no valid RINEX. All values will be stored modulo 299792.458 (speed of light). 2263 2263 </li> 2264 2264 <li> 2265 Using RTCM Version 2 .x, BNC will only handle message types 18 and 19 or 20 and 21 together with position and the antenna offset information carried in types 3 and 22. Note that processing carrier phase corrections and pseudo-range corrections contained in message types 20 and 21 needs access to broadcast ephemeris. Hence, whenever dealing with message types 20 and 21, make sure that broadcast ephemeris become available for BNC through also retrieving at least one RTCM Version 3.xstream carrying message types 1019 (GPS ephemeris) and 1020 (GLONASS ephemeris).2265 Using RTCM Version 2, BNC will only handle message types 18 and 19 or 20 and 21 together with position and the antenna offset information carried in types 3 and 22. Note that processing carrier phase corrections and pseudo-range corrections contained in message types 20 and 21 needs access to Broadcast Ephemeris. Hence, whenever dealing with message types 20 and 21, make sure that Broadcast Ephemeris become available for BNC through also retrieving at least one RTCM Version 3 stream carrying message types 1019 (GPS ephemeris) and 1020 (GLONASS ephemeris). 2266 2266 </li> 2267 2267 <li> 2268 BNC's 'Get Table' function only shows the STR records of a source-table. You can use an Internet browser to download the full source-table contents of any NTRIP broadcaster by simply entering its URL in the form of <u>http://host:port</u>. Data field number 8 in the NET records may provide information about where to register for an NTRIP broadcaster account.2268 BNC's 'Get Table' function only shows the STR records of a source-table. You can use an Internet browser to download the full source-table contents of any NTRIP Broadcaster by simply entering its URL in the form of <u>http://host:port</u>. Data field number 8 in the NET records may provide information about where to register for an NTRIP Broadcaster account. 2269 2269 </li> 2270 2270 <li> 2271 EUREF as well as IGS adhere to an open data policy. Streams are made available through NTRIP broadcasters at <u>www.euref-ip.net</u>, <u>www.igs-ip.net</u> and <u>products.igs-ip.net</u> free of charge to anyone for any purpose. There is no indication up until now how many users will need to be supported simultaneously. The given situation may develop in such a way that it might become difficult to serve all registered users at the same times. In cases where limited resources on the NTRIP broadcaster side (software restrictions, bandwidth limitation etc.) dictates, first priority in stream provision will be given to stream providers followed by re-broadcasting activities and real-time analysis centers while access to others might be temporarily denied.2271 EUREF as well as IGS adhere to an open data policy. Streams are made available through NTRIP Broadcasters at <u>www.euref-ip.net</u>, <u>www.igs-ip.net</u> and <u>products.igs-ip.net</u> free of charge to anyone for any purpose. There is no indication up until now how many users will need to be supported simultaneously. The given situation may develop in such a way that it might become difficult to serve all registered users at the same times. In cases where limited resources on the NTRIP Broadcaster side (software restrictions, bandwidth limitation etc.) dictates, first priority in stream provision will be given to stream providers followed by re-broadcasting activities and real-time analysis centers while access to others might be temporarily denied. 2272 2272 </li> 2273 2273 <li> … … 2280 2280 The BKG Ntrip Client (BNC) Qt Graphic User Interface (GUI) has been developed for the Federal Agency for Cartography and Geodesy (BKG) by Leos Mervart, Czech Technical University Prague, Department of Geodesy. BNC includes the following GNU GPL software components: 2281 2281 <ul> 2282 <li> RTCM 2 .xdecoder, written by Oliver Montenbruck, German Space Operations Center, DLR, Oberpfaffenhofen</li>2283 <li> RTCM 3 .xdecoder, written for BKG by Dirk Stoecker, Alberding GmbH, Schoenefeld</li>2282 <li> RTCM 2 decoder, written by Oliver Montenbruck, German Space Operations Center, DLR, Oberpfaffenhofen</li> 2283 <li> RTCM 3 decoder, written for BKG by Dirk Stoecker, Alberding GmbH, Schoenefeld</li> 2284 2284 </ul> 2285 2285 </p> … … 2295 2295 Scott Glazier, OmniSTAR Australia has been helpful in finding BNC's bugs.<br> 2296 2296 James Perlt, BKG, helped fixing bugs and redesigned BNC's main window.<br> 2297 Andre Hauschild, German Space Operations Center, DLR, revised the RTCM v2 decoder.<br>2298 Zdenek Lukes, Czech Technical University Prague, Department of Geodesy, extended the RTCM v2 decoder to handle message types 3, 20, 21, and 22 and added loss of lock indicator.<br>2297 Andre Hauschild, German Space Operations Center, DLR, revised the RTCM Version 2 decoder.<br> 2298 Zdenek Lukes, Czech Technical University Prague, Department of Geodesy, extended the RTCM Version 2 decoder to handle message types 3, 20, 21, and 22 and added loss of lock indicator.<br> 2299 2299 Jan Dousa, Geodetic Observatory Pecny, Czech Republic, provided a tool for drawing stream distribution maps and also helped with fixing bugs.<br> 2300 2300 Denis Laurichesse, Centre National d'Etudes Spatiales (CNES), suggested to synchronize observations and clock corrections to reduce high frequency noise in PPP solutions. … … 2307 2307 6.2.1 NTRIP <a href=#ntrip1>Version 1</a><br> 2308 2308 6.2.2 NTRIP <a href=#ntrip2>Version 2</a><br> 2309 6.2.3 RTCM <a href=#rtcm2>Version 2 .x</a><br>2310 6.2.4 RTCM <a href=#rtcm3>Version 3 .x</a><br>2309 6.2.3 RTCM <a href=#rtcm2>Version 2</a><br> 2310 6.2.4 RTCM <a href=#rtcm3>Version 3</a><br> 2311 2311 6.3. <a href=#config>Configuration Example</a><br> 2312 2312 6.4. <a href=#links>Links</a><br> … … 2344 2344 <tr> 2345 2345 <td>Apr 2008 </td><td>Version 1.5 </td> 2346 <td>[Add] Handle ephemeris from RTCM Version 3 .xstreams<br> [Add] Upgrade to Qt Version 4.3.2<br> [Add] Optional RINEX v3 output<br> [Add] SBAS support<br> [Bug] RINEX skeleton download following stream outage<br> [Add] Handle ephemeris from RTIGS streams<br> [Add] Monitor stream failure/recovery and latency<br> [Mod] Redesign of main window<br> [Bug] Freezing of About window on Mac systems<br> [Bug] Fixed problem with PRN 32 in RTCMv2 decoder<br> [Bug] Fix for Trimble 4000SSI receivers in RTCMv2 decoder<br> [Mod] Major revision of input buffer in RTCMv2 decoder</td>2346 <td>[Add] Handle ephemeris from RTCM Version 3 streams<br> [Add] Upgrade to Qt Version 4.3.2<br> [Add] Optional RINEX v3 output<br> [Add] SBAS support<br> [Bug] RINEX skeleton download following stream outage<br> [Add] Handle ephemeris from RTIGS streams<br> [Add] Monitor stream failure/recovery and latency<br> [Mod] Redesign of main window<br> [Bug] Freezing of About window on Mac systems<br> [Bug] Fixed problem with PRN 32 in RTCMv2 decoder<br> [Bug] Fix for Trimble 4000SSI receivers in RTCMv2 decoder<br> [Mod] Major revision of input buffer in RTCMv2 decoder</td> 2347 2347 </tr> 2348 2348 … … 2369 2369 <tr> 2370 2370 <td>Feb 2010 </td><td>Version 2.0 </td> 2371 <td>[Mod] Change sign of Broadcast Ephemeris correctors<br> [Add] Real-time PPP option</td>2371 <td>[Mod] Change sign of Broadcast Corrections<br> [Add] Real-time PPP option</td> 2372 2372 </tr> 2373 2373 … … 2389 2389 <tr> 2390 2390 <td>Dec 2010 </td><td>Version 2.4 </td> 2391 <td>[Add] Output of averaged positions when in PPP mode<br> [Mod] Use always the latest received set of broadcast ephemeris<br> [Add] QuickStart PPP option<br> [Mod] Improvement of data sharing efficiency among different threads<br> [Mod] Design of PPP tab section<br> [Add] Sigmas for observations and parameters<br> [Add] Stream distribution map<br> [Bug] GPS Ephemeris in RINEX v3 format</td>2391 <td>[Add] Output of averaged positions when in PPP mode<br> [Mod] Use always the latest received set of Broadcast Ephemeris<br> [Add] QuickStart PPP option<br> [Mod] Improvement of data sharing efficiency among different threads<br> [Mod] Design of PPP tab section<br> [Add] Sigmas for observations and parameters<br> [Add] Stream distribution map<br> [Bug] GPS Ephemeris in RINEX v3 format</td> 2392 2392 </tr> 2393 2393 2394 2394 <tr> 2395 2395 <td>Feb 2011 </td><td>Version 2.5 </td> 2396 <td>[Add] PPP option for sync of clock observations and corrections<br> [Add] Drafted RTCMv3 Galileo ephemeris messages 1045<br> [Add] Drafted RTCMv3 Multipe Signal Messages<br> [Add] Optional specification of sigmas for coordinates and troposphere in PPP<br> [Add] Include Galileo in SPP<br> [Add] Include Galileo observations in output via IP port<br> [Add] Include Galileo observations in output via RINEXv3 files<br> [Mod] Interface format for feeding a real-time engine with observations<br> [Add] Correct observations for antenna phase center offsets<br> [Add] Combine orbit/clock correct orsstreams<br> [Add] Specify corrections mountpoint in PPP tab</td>2396 <td>[Add] PPP option for sync of clock observations and corrections<br> [Add] Drafted RTCMv3 Galileo ephemeris messages 1045<br> [Add] Drafted RTCMv3 Multipe Signal Messages<br> [Add] Optional specification of sigmas for coordinates and troposphere in PPP<br> [Add] Include Galileo in SPP<br> [Add] Include Galileo observations in output via IP port<br> [Add] Include Galileo observations in output via RINEXv3 files<br> [Mod] Interface format for feeding a real-time engine with observations<br> [Add] Correct observations for antenna phase center offsets<br> [Add] Combine orbit/clock correction streams<br> [Add] Specify corrections mountpoint in PPP tab</td> 2397 2397 </tr> 2398 2398 … … 2429 2429 2430 2430 <p> 2431 NTRIP is implemented in three system software components: NTRIP clients, NTRIP servers and NTRIP broadcasters. The NTRIP broadcaster is the actual HTTP server program whereas NTRIP client and NTRIP server are acting as HTTP clients.2431 NTRIP is implemented in three system software components: NTRIP Clients, NTRIP Servers and NTRIP Broadcasters. The NTRIP Broadcaster is the actual HTTP server program whereas NTRIP Client and NTRIP Server are acting as HTTP clients. 2432 2432 </p> 2433 2433 … … 2444 2444 2445 2445 <p> 2446 The NTRIP broadcaster maintains a source-table containing information on available NTRIP streams, networks of NTRIP streams and NTRIP broadcasters. The source-table is sent to an NTRIP client on request. Source-table records are dedicated to one of the following: Data Streams (record type STR), Casters (record type CAS), or Networks of streams (record type NET).2446 The NTRIP Broadcaster maintains a source-table containing information on available NTRIP streams, networks of NTRIP streams and NTRIP Broadcasters. The source-table is sent to an NTRIP Client on request. Source-table records are dedicated to one of the following: Data Streams (record type STR), Casters (record type CAS), or Networks of streams (record type NET). 2447 2447 </p> 2448 2448 … … 2475 2475 </p> 2476 2476 2477 <p><a name="rtcm2"><h4>6.2.3 RTCM Version 2 .x</h4></p>2478 <p> 2479 Transmitting GNSS carrier phase data can be done through RTCM Version 2 .xmessages. Please note that only RTCM Version 2.2 and 2.3 streams may include GLONASS data. Messages that may be of some interest here are:2477 <p><a name="rtcm2"><h4>6.2.3 RTCM Version 2</h4></p> 2478 <p> 2479 Transmitting GNSS carrier phase data can be done through RTCM Version 2 messages. Please note that only RTCM Version 2.2 and 2.3 streams may include GLONASS data. Messages that may be of some interest here are: 2480 2480 </p> 2481 2481 … … 2513 2513 </ul> 2514 2514 2515 <p><a name="rtcm3"><h4>6.2.4 RTCM Version 3 .x</h4></p>2516 <p> 2517 RTCM Version 3 .x has been developed as a more efficient alternative to RTCM Version 2.x. Service providers and vendors have asked for a standard that would be more efficient, easy to use, and more easily adaptable to new situations. The main complaint was that the Version 2 parity scheme was wasteful of bandwidth. Another complaint was that the parity is not independent from word to word. Still another was that even with so many bits devoted to parity, the actual integrity of the message was not as high as it should be. Plus, 30-bit words are awkward to handle. The Version 3.xstandard is intended to correct these weaknesses.2518 </p> 2519 <p> 2520 RTCM Version 3 .xdefines a number of message types. Messages that may be of interest here are:2515 <p><a name="rtcm3"><h4>6.2.4 RTCM Version 3</h4></p> 2516 <p> 2517 RTCM Version 3 has been developed as a more efficient alternative to RTCM Version 2. Service providers and vendors have asked for a standard that would be more efficient, easy to use, and more easily adaptable to new situations. The main complaint was that the Version 2 parity scheme was wasteful of bandwidth. Another complaint was that the parity is not independent from word to word. Still another was that even with so many bits devoted to parity, the actual integrity of the message was not as high as it should be. Plus, 30-bit words are awkward to handle. The Version 3 standard is intended to correct these weaknesses. 2518 </p> 2519 <p> 2520 RTCM Version 3 defines a number of message types. Messages that may be of interest here are: 2521 2521 <ul> 2522 2522 <li>Type 1001, GPS L1 code and phase.</li> … … 2670 2670 <tr><td>postObsFile=</td><td>PPP Client: Observations file</td></tr> 2671 2671 <tr><td>postNavFile=</td><td>PPP Client: Navigation file</td></tr> 2672 <tr><td>postCorrFile=</td><td>PPP Client: Correct ors file</td></tr>2672 <tr><td>postCorrFile=</td><td>PPP Client: Corrections file</td></tr> 2673 2673 <tr><td>postOutFile=</td><td>PPP Client: Output file</td></tr> 2674 2674 <tr><td>pppAntenna=</td><td>PPP Client: Antenna name</td></tr> … … 2707 2707 <tr><td>reqcNewReceiverName=</td><td>Reqc: New receiver</td></tr> 2708 2708 2709 <tr><td>combineStreams=</td><td>Combination: List of correct orsstreams</td></tr>2709 <tr><td>combineStreams=</td><td>Combination: List of correction streams</td></tr> 2710 2710 <tr><td>cmbMethod=Filter</td><td>Combination: Approach</td></tr> 2711 2711 <tr><td>cmbMaxres=</td><td>Combination: Clock outlier threshold</td></tr> … … 2752 2752 <tr></tr> 2753 2753 <tr><td>NTRIP </td><td><u>http://igs.bkg.bund.de/ntrip/index</u></td></tr> 2754 <tr><td>EUREF-IP NTRIP broadcaster </td><td><u>http://www.euref-ip.net/home</u></td></tr>2755 <tr><td>IGS-IP NTRIP broadcaster </td><td><u>http://www.igs-ip.net/home</u></td></tr>2756 <tr><td>IGS products NTRIP broadcaster </td><td><u>http://products.igs-ip.net/home</u></td></tr>2757 <tr><td>IGS M-GEX NTRIP broadcaster </td><td><u>http://mgex.igs-ip.net/home</u></td></tr>2754 <tr><td>EUREF-IP NTRIP Broadcaster </td><td><u>http://www.euref-ip.net/home</u></td></tr> 2755 <tr><td>IGS-IP NTRIP Broadcaster </td><td><u>http://www.igs-ip.net/home</u></td></tr> 2756 <tr><td>IGS products NTRIP Broadcaster </td><td><u>http://products.igs-ip.net/home</u></td></tr> 2757 <tr><td>IGS M-GEX NTRIP Broadcaster </td><td><u>http://mgex.igs-ip.net/home</u></td></tr> 2758 2758 <tr><td>Distribution of IGS-IP streams </td><td><u>http://www.igs.oma.be/real_time/</u></td></tr> 2759 2759 <tr><td>Completeness and latency of IGS-IP data </td><td><u>http://www.igs.oma.be/highrate/</u></td></tr> 2760 <tr><td>NTRIP broadcaster overview </td><td><u>http://www.rtcm-ntrip.org/home</u></td></tr>2760 <tr><td>NTRIP Broadcaster overview </td><td><u>http://www.rtcm-ntrip.org/home</u></td></tr> 2761 2761 <tr><td>NTRIP Open Source software code </td><td><u>http://software.rtcm-ntrip.org</u></td></tr> 2762 2762 <tr><td>EUREF-IP Project </td><td><u>http://www.epncb.oma.be/euref_IP</u></td></tr>
Note:
See TracChangeset
for help on using the changeset viewer.
