- Timestamp:
- May 21, 2012, 2:46:51 PM (12 years ago)
- File:
-
- 1 edited
-
trunk/BNC/bnchelp.html (modified) (46 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/BNC/bnchelp.html
r4191 r4197 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>, <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. 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 6 </p> 7 <p> 8 <u>http://www.euref-ip.net/home</u>,<br> 9 <u>http://www.igs-ip.net/home</u>,<br> 10 <u>http://products.igs-ip.net/home</u>, or<br> 11 <u>http://mgex.igs-ip.net/home</u>. 12 </p> 13 <p> 14 Although actually meant as a real-time tool, it comes with some limited Post Processing functionality. 6 15 </p> 7 16 … … 11 20 12 21 <p> 13 BNC has been written under GNU General Public License (GPL). Binaries for BNC are available for Windows, 32-bit Linux, 64-bit Linux (compiled under -m32 32-bit compatibility mode), Solaris, and Mac systems. We used the MinGW Version 4.4.0 compiler to create the Windows binary. It is likely that BNC can be compiled on other systems where a GNU compiler and Qt Version 4.7.3 are installed.14 </p> 15 16 <p> 17 Please ensure that you have installed the latest version of BNC available from <u>http://igs.bkg.bund.de/ntrip/download</u>. We are continuously working on the program and would appreciate if you could sendcomments, suggestions, or bug reports to [euref-ip@bkg.bund.de] or [igs-ip@bkg.bund.de].22 BNC has been written under GNU General Public License (GPL). Source code is available from Subversion software archive <u>http://software.rtcm-ntrip.org/svn/trunk/BNC.</u> Binaries for BNC are available for Windows, 32-bit Linux, 64-bit Linux (compiled under -m32 32-bit compatibility mode), Solaris, and Mac systems. We used the MinGW Version 4.4.0 compiler to create the Windows binary. It is likely that BNC can be compiled on other systems where a GNU compiler and Qt Version 4.7.3 are installed. 23 </p> 24 25 <p> 26 Please ensure that you have installed the latest version of BNC available from <u>http://igs.bkg.bund.de/ntrip/download</u>. Feel free to send us comments, suggestions, or bug reports to [euref-ip@bkg.bund.de] or [igs-ip@bkg.bund.de]. 18 27 </p> 19 28 … … 28 37 <p> 29 38 <b><a name="authors">Authors</b><br> 30 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: 31 <ul> 32 <li> RTCM 2 decoder, written by Oliver Montenbruck, German Space Operations Center, DLR, Oberpfaffenhofen</li> 33 <li> RTCM 3 decoder for standard messages and a RTCM 3 encoder & decoder for SSR messages, both written for BKG by Dirk Stoecker, Alberding GmbH, Schoenefeld</li> 39 The BKG Ntrip Client (BNC) Qt Graphic User Interface (GUI) has been developed for the Federal Agency for Cartography and Geodesy (BKG) by 40 </p> 41 <p> 42 Leos Mervart<br> 43 Czech Technical University (CTU)<br> 44 Department of Geodesy<br> 45 Prague, Czech Republic 46 </p> 47 <p> 48 BNC includes the following GNU GPL software components: 49 <ul> 50 <li> RTCM 2 decoder, written by Oliver Montenbruck, German Space Operations Center, DLR, Oberpfaffenhofen, Germany</li> 51 <li> RTCM 3 decoder for standard messages and a RTCM 3 encoder & decoder for SSR messages, both written for BKG by Dirk Stoecker, Alberding GmbH, Schoenefeld, Germany</li> 34 52 </ul> 35 53 </p> … … 37 55 Georg Weber<br> 38 56 Federal Agency for Cartography and Geodesy (BKG)<br> 57 Department of Geodesy<br> 39 58 Frankfurt, Germany<br> 40 [euref-ip@bkg.bund.de] or [igs-ip@bkg.bund.de] 59 [euref-ip@bkg.bund.de] or<br> 60 [igs-ip@bkg.bund.de] 41 61 </p> 42 62 43 63 <p> 44 64 <b>Acknowledgements</b><br> 45 BNC's Help Contents has been proofread by Thomas Yan, University of New South Wales, Australia.<br>65 Earlier versions of BNC's Help Contents have been proofread by Thomas Yan, University of New South Wales, Australia. He also provided pre-compiled builds of BNC for Mac systems.<br> 46 66 Scott Glazier, OmniSTAR Australia has been helpful in finding BNC's bugs.<br> 47 67 James Perlt, BKG, helped fixing bugs and redesigned BNC's main window.<br> … … 67 87 <li>feed a stream into a GNSS receiver via serial communication link,</li> 68 88 <li>carry out a real-time Precise Point Positioning to determine a GNSS rover position,</li> 69 <li>simultaneously process several incoming orbit and clock correction streams to produce, encode and upload a combination solution,</li>89 <li>simultaneously process several Broadcast Correction streams to produce, encode and upload combined Broadcast Corrections,</li> 70 90 <li>upload a Broadcast Ephemeris stream in RTCM Version 3 format,</li> 71 <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>72 <ul> 73 <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>74 <li>upload the clock and orbit corrections as an RTCM Version 3 stream to an NTRIP Broadcaster,</li>91 <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. BNC will then</li> 92 <ul> 93 <li>convert the IGS Earth-Centered-Earth-Fixed clocks and and orbits into Broadcast Corrections with radial, along-track and cross-track components,</li> 94 <li>upload Broadcast Corrections as an RTCM Version 3 stream to an NTRIP Broadcaster,</li> 75 95 <li>refer the clock and orbit corrections to a specific reference system,</li> 76 <li>log the Broadcast Ephemeris clock corrections as Clock RINEX files for further processing using other tools than BNC,</li>77 <li>log the Broadcast Ephemeris orbit corrections as SP3 files for further processing using other tools than BNC,</li>96 <li>log the Broadcast Corrections as Clock RINEX files for further processing using other tools than BNC,</li> 97 <li>log the Broadcast Corrections as SP3 files for further processing using other tools than BNC,</li> 78 98 </ul> 79 99 <li>edit or concatenate RINEX files or check their quality.</li> … … 87 107 <ul> 88 108 <li>RTCM Version 2 message types for GPS and GLONASS observations, </li> 89 <li>RTCM Version 3 'conventional' message types for observations and Broadcast Ephemeris for GPS, GLONASS, SBAS , Galileo, COMPASS, and QZSS,</li>109 <li>RTCM Version 3 'conventional' message types for observations and Broadcast Ephemeris for GPS, GLONASS, SBAS and Galileo (coming soon: COMPASS and QZSS),</li> 90 110 <li>RTCM Version 3 'State Space Representation' (SSR) messages for GPS, GLONASS and Galileo,</li> 91 <li> RTCM Version 3 'Multiple Signal Messages' (MSM) and 'High Precision Multiple Signal Messages' (HP MSM),</li>111 <li>Drafted RTCM Version 3 'Multiple Signal Messages' (MSM) and 'High Precision Multiple Signal Messages' (HP MSM),</li> 92 112 <li>RTNET, a plain ASCII format defined within BNC to receive orbits and clock from a serving GNSS engine. 93 113 </ul> … … 96 116 97 117 <p> 98 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 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.118 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. 99 119 </p> 100 120 <p><img src="IMG/screenshot10.png"/></p> … … 109 129 </p> 110 130 <p><img src="IMG/screenshot02.png"/></p> 111 <p><u>Figure 3:</u> Flowchart, BNC feeding a real-time GNSS engine and uploading an encoded Broadcast Corrections stream.</p>131 <p><u>Figure 3:</u> Flowchart, BNC feeding a real-time GNSS engine and uploading encoded Broadcast Corrections.</p> 112 132 113 133 <p> … … 194 214 3.7.2. <a href=#corrint>Interval</a><br> 195 215 3.7.3. <a href=#corrport>Port</a><br> 196 3.7.4. <a href=#corrwait>Wait for Full Epoch</a><br>216 3.7.4. <a href=#corrwait>Wait for Full Corr Epoch</a><br> 197 217 3.8. <a href=#syncout>Feed Engine</a><br> 198 218 3.8.1. <a href=#syncport>Port</a><br> 199 3.8.2. <a href=#syncwait>Wait for Full Epoch</a><br>219 3.8.2. <a href=#syncwait>Wait for Full Obs Epoch</a><br> 200 220 3.8.3. <a href=#syncsample>Sampling</a><br> 201 221 3.8.4. <a href=#syncfile>File</a><br> … … 349 369 </p> 350 370 <p> 351 BNC comes with a help system providing online information about its functionality and usage. Short descriptions are available for any widget. Focus to the relevant widget and press Shift+F1 to request help information. A help text appears immediately; it disappears as soon as the user does something else. The dialogs on some operating systems may provide a "?" button that users can click; they thenclick the relevant widget to pop up the help text.371 BNC comes with a help system providing online information about its functionality and usage. Short descriptions are available for any widget. Focus to the relevant widget and press Shift+F1 to request help information. A help text appears immediately; it disappears as soon as the user does something else. The dialogs on some operating systems may provide a "?" button that users can click; click the relevant widget to pop up the help text. 352 372 </p> 353 373 … … 364 384 365 385 <p><a name="ssl"><h4>3.2.2 SSL - Transport Layer Security</h4></p> 366 <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 surewhether this is supported by the involved NTRIP Broadcaster. </p>386 <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. You may also just try communication via SSL to check out whether this is supported by the involved NTRIP Broadcaster. </p> 367 387 <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> 368 388 … … 374 394 <p><a name="genlog"><h4>3.3.1 Logfile - optional</h4></p> 375 395 <p> 376 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.396 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 be saved into a file. 377 397 </p> 378 398 … … 397 417 <p><a name="rawout"><h4>3.3.5 Raw Output File - optional</h4></p> 398 418 <p> 399 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.419 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 and it is not meant for Post Processing. 400 420 </p> 401 421 <p> … … 404 424 2010-08-03T18:05:28 RTCM3EPH RTCM_3 67 405 425 </pre> 426 </p> 427 <p> 406 428 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. 407 429 </p> … … 412 434 <p><a name="rinex"><h4>3.4. RINEX Observations</h4></p> 413 435 <p> 414 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.415 </p> 416 417 <p> 418 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 meantto not convert the affected stream contents but save its contents as received.436 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 and SBAS (coming soon: 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. 437 </p> 438 439 <p> 440 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' means to not convert the affected stream contents but save its contents as received. 419 441 </p> 420 442 <p><img src="IMG/screenshot16.png"/></p> … … 517 539 If neither a public nor a personal RINEX header skeleton file is available for BNC, a default header will be used. 518 540 </p> 541 <p> 542 The following is a skeleton example for a RINEX Version 2 file: 543 </p> 544 <p> 545 <pre> 546 OBSERVATION DATA G (GPS) RINEX VERSION / TYPE 547 DUND MARKER NAME 548 50212M003 MARKER NUMBER 549 4635120796 TRIMBLE NETRS 1.15 REC # / TYPE / VERS 550 12626150 TRM41249.00 NONE ANT # / TYPE 551 -4388121.1700 726671.0500 -4556535.6300 APPROX POSITION XYZ 552 0.0020 0.0000 0.0000 ANTENNA: DELTA H/E/N 553 GeoNet Reception GNS OBSERVER / AGENCY 554 PORTIONS OF THIS HEADER GENERATED BY BKG FROM COMMENT 555 SITELOG dund_20070806.log COMMENT 556 </pre> 557 <p> 519 558 520 559 <p><a name="rnxscript"><h4>3.4.6 Script - optional</h4></p> … … 536 575 <p><a name="ephemeris"><h4>3.5. RINEX Ephemeris</h4></p> 537 576 <p> 538 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 is577 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 539 578 </p> 540 579 <ul> … … 575 614 <p><a name="reqc"><h4>3.6. RINEX Editing & QC</h4></p> 576 615 <p> 577 Besides stream conversion from RTCM to RINEX, BNC allows editing RINEX files or concatenate their contents. RINEX observation and navigation files can be handled. BNC can also carry out a RINEX file contentsquality check. In summary this functionality in BNC covers578 <ul> 579 <li> stream <u>T</u>ranslation</li>580 <li> file <u>E</u>diting and concatenation</li>581 <li> file <u>Q</b></u>uality <u>C</u>heck</li>616 Besides stream conversion from RTCM to RINEX, BNC allows editing RINEX files or concatenate their contents. RINEX Observation and Navigation files can be handled. BNC can also carry out a RINEX file quality check. In summary this functionality in BNC covers 617 <ul> 618 <li>Stream <u>T</u>ranslation</li> 619 <li>File <u>E</u>diting and concatenation</li> 620 <li>File <u>Q</b></u>uality <u>C</u>heck</li> 582 621 </ul> 583 622 and hence follows UNAVCO's famous 'TEQC' program. The remarkable thing about BNC in this context is that it supports RINEX Version 3 under GNU General Public License. … … 599 638 <li>C1P in RINEX Version 3 is mapped to P1 in RINEX Version 2</li> 600 639 <li>C2P in RINEX Version 3 is mapped to P2 in RINEX Version 2</li> 601 <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 others.</li>602 </ul> 603 </p> 604 <p>Optionally you may specify a comment line text to be added to the emerging new RINEX file header. Any introduction of a newline through '\n' in this enforces the beginning of a further comment line. Comment line(s) will be added to the header after the 'PGM / RUN BY / DATE' record. Default is an empty option field meaning that no additional comment line isadded to the RINEX header.</p>640 <li>If several observations in RINEX Version 3 come with the same observation type and same band/frequency but different tracking modes, BNC uses only the one provided first for creating RINEX Version 2 while ignoring others.</li> 641 </ul> 642 </p> 643 <p>Optionally you may specify a comment line text to be added to the emerging new RINEX file header. Any introduction of a newline through '\n' in this enforces the beginning of a further comment line. Comment line(s) will be added to the header immediately after the 'PGM / RUN BY / DATE' record. Default is an empty option field meaning that no additional comment line will be added to the RINEX header.</p> 605 644 <p>Specifying a 'RUN BY' string to be included in the emerging new RINEX file header is another option. Default is an empty option field meanig the operator's ID is automatically used as 'RUN BY' string.</p> 606 645 <p> … … 613 652 <p><a name="reqcinput"><h4>3.6.3 Input Files - mandatory if 'Action' is set</h4></p> 614 653 <p> 615 Specify full path to input RINEX observation file(s), and<br>616 specify full path to input RINEX navigation file(s).654 Specify full path to input RINEX Observation file(s), and<br> 655 specify full path to input RINEX Navigation file(s). 617 656 </p> 618 657 <p>When specifying several input files BNC will concatenate their contents.</p> … … 620 659 <p><a name="reqcoutput"><h4>3.6.4 Output Files - mandatory if 'Action' is set</h4></p> 621 660 <p> 622 If 'Edit/Concatenate' is selected, specifying the a path to output RINEX observation file(s) and specifying a full path to output RINEX navigation file(s) is mandatory.</p>661 If 'Edit/Concatenate' is selected, specifying the a path to output RINEX Observation file(s) and specifying a full path to output RINEX Navigation file(s) is mandatory.</p> 623 662 624 663 <p> … … 661 700 <tr><td><b>Keyname</b></td><td><b>Meaning</b></td></tr> 662 701 <tr><td>reqcAction</td><td>RINEX Editing & QC action</td></tr> 663 <tr><td>reqcObsFile</td><td>RINEX observation input file(s)</td></tr>664 <tr><td>reqcNavFile</td><td>RINEX navigation input files(s)</td></tr>665 <tr><td>reqcOutObsFile</td><td>RINEX observation output file</td></tr>666 <tr><td>reqcOutNavFile</td><td>RINEX navigation output file</td></tr>702 <tr><td>reqcObsFile</td><td>RINEX Observation input file(s)</td></tr> 703 <tr><td>reqcNavFile</td><td>RINEX Navigation input files(s)</td></tr> 704 <tr><td>reqcOutObsFile</td><td>RINEX Observation output file</td></tr> 705 <tr><td>reqcOutNavFile</td><td>RINEX Navigation output file</td></tr> 667 706 <tr><td>reqcOutLogFile</td><td>Logfile</td></tr> 668 707 <tr><td>reqcRnxVersion</td><td>RINEX version of emerging new file</td></tr> … … 688 727 </p> 689 728 <p> 690 RTCM has developed Version 3 messages to transport satellite clock and orbit corrections in real-time. The current set of messages concerns:729 RTCM has developed Version 3 messages to transport satellite clock and orbit corrections in real-time. The current set of SSR messages concerns: 691 730 <ul> 692 731 <li>Orbit corrections to Broadcast Ephemeris</li> … … 791 830 </pre> 792 831 <p> 793 In case of RTCM message types 1058 or 1064 (see Annex) the first five parameters are followed by832 In case of RTCM message types 1058 or 1064 (see Annex) the first five parameters in each record are followed by 794 833 </p> 795 834 <ul> … … 814 853 </p> 815 854 <p> 816 In case of RTCM message types 1060 or 1066 (see Annex) the first five parameters are followed by855 In case of RTCM message types 1060 or 1066 (see Annex) the first five parameters in each record are followed by 817 856 <p> 818 857 <ul> … … 843 882 </p> 844 883 <p> 845 In case of RTCM message types 1059 or 1065 (see Annex) the first five parameters are followed by884 In case of RTCM message types 1059 or 1065 (see Annex) the first five parameters in each record are followed by 846 885 <ul> 847 886 <li>Number of Code Biases</li> … … 917 956 </p> 918 957 919 <p><a name="corrwait"><h4>3.7.4 Wait for Full Epoch - mandatory if 'Port' is set</h4></p>920 <p> 921 When feeding a real-time GNSS network engine waiting epoch by epoch for synchronized Broadcast Corrections, BNC drops (only concerning IP port output) whatever is received later than 'Wait for full epoch' seconds. A value of 2 to 5 seconds could be an appropriate choice for that, depending on the latency of the incoming Broadcast Corrections stream and the delay acceptable by your application. A message such as "COCK1: Correction overaged by 5 sec" shows up in BNC's logfile if 'Wait for fullepoch' is exceeded.958 <p><a name="corrwait"><h4>3.7.4 Wait for Full Corr Epoch - mandatory if 'Port' is set</h4></p> 959 <p> 960 When feeding a real-time GNSS network engine (see 'Feed Engine') waiting epoch by epoch for synchronized Broadcast Corrections, or when you 'Combine Corrections' BNC drops (only concerning IP port output) whatever is received later than 'Wait for full corr epoch' seconds. A value of 2 to 5 seconds could be an appropriate choice for that, depending on the latency of the incoming Broadcast Corrections stream and the delay acceptable by your application. A message such as "COCK1: Correction overaged by 5 sec" shows up in BNC's logfile if 'Wait for full corr epoch' is exceeded. 922 961 </p> 923 962 <p> … … 985 1024 <p><a name="syncport"><h4>3.8.1 Port - optional</h4></p> 986 1025 <p> 987 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 data for any specific epoch which become available within a certain number of latency seconds (see 'Wait for FullEpoch' option). It then - epoch by epoch - outputs whatever has been received. 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>988 </p> 989 990 <p><a name="syncwait"><h4>3.8.2 Wait for Full Epoch - mandatory if 'Port' is set</h4></p>991 <p> 992 When feeding a real-time GNSS network engine waiting for synchronized input epoch by epoch, BNC drops whatever is received later than 'Wait for full epoch' seconds. A value of 3 to 5 seconds could be an appropriate choice for that, depending on the latency of the incoming streams and the delay acceptable for your real-time GNSS product. Default value for 'Wait for fullepoch' is 5 seconds.993 </p> 994 <p> 995 Note that 'Wait for full epoch' does not affect the RINEX Observation file content. Observations received later than 'Wait for fullepoch' seconds will still be included in the RINEX Observation files.1026 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 any specific epoch which become available within a certain number of latency seconds (see 'Wait for Full Obs Epoch' option). It then - epoch by epoch - outputs whatever has been received. 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> 1027 </p> 1028 1029 <p><a name="syncwait"><h4>3.8.2 Wait for Full Obs Epoch - mandatory if 'Port' is set</h4></p> 1030 <p> 1031 When feeding a real-time GNSS network engine waiting for synchronized observations epoch by epoch, BNC drops whatever is received later than 'Wait for full obs epoch' seconds. A value of 3 to 5 seconds could be an appropriate choice for that, depending on the latency of the incoming streams and the delay acceptable for your real-time GNSS product. Default value for 'Wait for full obs epoch' is 5 seconds. 1032 </p> 1033 <p> 1034 Note that 'Wait for full obs epoch' does not affect the RINEX Observation file content. Observations received later than 'Wait for full obs epoch' seconds will still be included in the RINEX Observation files. 996 1035 </p> 997 1036 … … 1011 1050 <p><a name="syncuport"><h4>3.8.5 Port (unsynchronized) - optional</h4></p> 1012 1051 <p> 1013 BNC can produce unsynchronized observations from all configured streams in ASCII format on your local host (IP 127.0.0.1) through an IP 'Port'. Unsynchronized means that BNC immediately forwards any received observation to the port. Specify an IP port number here to activate this function. The default is an empty option field, meaning that no binaryunsynchronized output is generated.</p>1052 BNC can produce unsynchronized observations from all configured streams in ASCII format on your local host (IP 127.0.0.1) through an IP 'Port'. Unsynchronized means that BNC immediately forwards any received observation to the port. Specify an IP port number here to activate this function. The default is an empty option field, meaning that no unsynchronized output is generated.</p> 1014 1053 <p> 1015 1054 1016 1055 <p><a name="serial"><h4>3.9. Serial Output</h4></p> 1017 1056 <p> 1018 You may use BNC to feed a serial connected device like an GNSS receiver. For that an incoming stream s 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 connectedrover.1057 You may use BNC to feed a serial connected device like an GNSS receiver. For that an incoming stream 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 RTK rover. 1019 1058 </p> 1020 1059 <p><img src="IMG/screenshot11.png"/></p> 1021 <p><u>Figure 9:</u> BNC pulling a VRS stream to feed a serial connected rover.</p>1060 <p><u>Figure 9:</u> BNC pulling a VRS stream to feed a serial connected RTK rover.</p> 1022 1061 1023 1062 <p><a name="sermount"><h4>3.9.1 Mountpoint - optional</h4></p> … … 1142 1181 FFMJ0 End_Outage 08-02-21 11:36:02 Begin was 08-02-21 09:25:59 1143 1182 </pre> 1183 </p> 1184 <p> 1144 1185 Sample script for Unix/Linux/Mac systems: 1186 </p> 1145 1187 <pre> 1146 1188 #!/bin/bash … … 1177 1219 <p><a name="miscperf"><h4>3.11.2 Log Latency - optional </h4></p> 1178 1220 <p> 1179 BNC can average latencies per stream over a certain period of GPS time, the 'Log latency' interval. Mean latencies are calculated from the individual latencies of at most one (first incoming) observation or correction to Broadcast Ephemeris per second. The mean latencies are then saved in BNC's logfile. Note that computing correct latencies requires the clock of the host computer to be properly synchronized. Note further that the latencies availablefrom the 'Latency' tab on the bottom of the main window represent individual latencies and not the mean latencies for the logfile.1221 BNC can average latencies per stream over a certain period of GPS time, the 'Log latency' interval. Mean latencies are calculated from the individual latencies of one (first incoming) observation or Broadcast Correction per second. The mean latencies are then saved in BNC's logfile. Note that computing correct latencies requires the clock of the host computer to be properly synchronized. Note further that visualized latencies from the 'Latency' tab on the bottom of the main window represent individual latencies and not the mean latencies for the logfile. 1180 1222 </p> 1181 1223 <p> … … 1254 1296 </p> 1255 1297 <p> 1256 The 'PPP' string in that is followed by the selected mounpoint,a PPP time stamp in GPS Time, the number of processed satellites, and XYZ coordinates with their formal errors as derived from the implemented filter in [m]. The implemented algorithm includes outlier and cycle slip detection. The maximum for accepted residuals is hard coded to 10 meters for code observations and 10 centimeters for phase observations.1298 The selected mountpoint in that is followed by a PPP time stamp in GPS Time, the number of processed satellites, and XYZ coordinates with their formal errors as derived from the implemented filter in [m]. The implemented algorithm includes outlier and cycle slip detection. The maximum for accepted residuals is hard coded to 10 meters for code observations and 10 centimeters for phase observations. 1257 1299 </p> 1258 1300 … … 1267 1309 </ul> 1268 1310 These parameters are saved together with their standard deviation. The following is an example extract from a log file when BNC was in 'Single Point Positioning' (SPP) mode: 1311 </p> 1312 <p> 1269 1313 <pre> 1270 1314 10-12-06 18:10:50 Single Point Positioning of Epoch 18:10:48.0 … … 1326 1370 1327 1371 <p> 1328 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 correctors, and Broadcast Ephemeris. Such a file must be generated using BNC's 'Raw output file' option. Example: 1329 </p> 1330 1331 <p> 1332 bnc.exe --conf c:\temp\BNC.ppp --file c:\temp\FFMJ1 1372 Note that BNC's 'PPP' option can also be used offline either for for debugging or for Post Processing purposes. 1373 <ul> 1374 <li> 1375 <u>Debugging:</u> Apply the 'File Mode' 'Command Line' option for that to read a file containing synchronized observations, orbit and clock correctors, and Broadcast Ephemeris. Such a file must be generated before using BNC's 'Raw output file' option. Example:<br> 1376 bnc.exe --conf c:\temp\PPP.bnc --file c:\temp\FFMJ1 1377 </li> 1378 <li> 1379 <u>Post Processing:</u> Apply the 'Post Processing' option as described below. 1380 </li> 1381 </ul> 1333 1382 </p> 1334 1383 … … 1348 1397 <p><a name="pppmode"><h4>3.12.1 Mode & Mountpoints - optional</h4></p> 1349 1398 <p> 1350 Specify the Point Positioning mode you want to apply and the mountpoints for observations and Broadcast Corrections. 1399 Specify the Point Positioning mode you want to apply and the mountpoints for observations and Broadcast Corrections. Options are 'Realtime-PPP', 'Realtime-SPP', and 'Post-Processing'. 1351 1400 </p> 1352 1401 … … 1421 1470 <p><a name="ppppost"><h4>3.12.5 Post Processing - optional</h4></p> 1422 1471 <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> 1423 <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.1472 <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. 1424 1473 <p> 1425 1474 Post Processing PPP results can be saved in a specific output file. … … 1652 1701 </p> 1653 1702 <p> 1654 Note that an appropriate 'Wait for full epoch' value needs to be specified for the combination under the 'Broadcast Corrections' tab. To give an example: a value of '15' sec would make sense if the update rate of incoming clock corrections is 10 sec.1703 Note that an appropriate 'Wait for full corr epoch' value needs to be specified for the combination under the 'Broadcast Corrections' tab. To give an example: a value of '15' sec would make sense if the update rate of incoming clock corrections is 10 sec. 1655 1704 </p> 1656 1705 <p> … … 2435 2484 <tr> 2436 2485 <td>Nov 2009 </td><td>Version 1.7 </td> 2437 <td>[Bug] RINEX navigation file format<br> [Add] Upgrade to Qt Version 4.5.2<br> [Add] Support of NTRIP v2<br> [Add] Rover support via serial port<br> [Add] Show broadcaster table from www.rtcm-ntrip.org<br> [Add] Enable/disable tab widgets<br> [Add] User defined configuration file name<br> [Mod] Switch to configuration files in ini-Format<br> [Add] Daily logfile rotation<br> [Add] Read from TCP/IP port, by-pass NTRIP transport protocol<br> [Add] Save NMEA messages coming from rover<br> [Add] Auto start<br> [Add] Drag and drop ini files<br> [Add] Read from serial port, by-pass NTRIP transport protocol<br> [Mod] Update of SSR messages following RTCM 091-2009-SC104-542<br> [Add] Read from UPD port, by-pass NTRIP transport protocol<br> [Mod] Output format of Broadcast Corrections<br> [Add] Throughput plot<br> [Add] Latency plot</td>2486 <td>[Bug] RINEX Navigation file format<br> [Add] Upgrade to Qt Version 4.5.2<br> [Add] Support of NTRIP v2<br> [Add] Rover support via serial port<br> [Add] Show broadcaster table from www.rtcm-ntrip.org<br> [Add] Enable/disable tab widgets<br> [Add] User defined configuration file name<br> [Mod] Switch to configuration files in ini-Format<br> [Add] Daily logfile rotation<br> [Add] Read from TCP/IP port, by-pass NTRIP transport protocol<br> [Add] Save NMEA messages coming from rover<br> [Add] Auto start<br> [Add] Drag and drop ini files<br> [Add] Read from serial port, by-pass NTRIP transport protocol<br> [Mod] Update of SSR messages following RTCM 091-2009-SC104-542<br> [Add] Read from UPD port, by-pass NTRIP transport protocol<br> [Mod] Output format of Broadcast Corrections<br> [Add] Throughput plot<br> [Add] Latency plot</td> 2438 2487 </tr> 2439 2488 … … 2672 2721 </li> 2673 2722 </ul> 2674 Presented example configuration files contain a user ID 'user' and a password 'pass' for accessing streams from various Ntrip broadcasters. Replace these account details by a the personal user ID and password you receive following an online registration through <u>http://register.rtcm-ntrip.org</u>.2675 </p> 2676 <p> 2677 Note that the account for an Ntrip broadcaster is usually limited to pulling a certain 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.2723 Presented example configuration files contain a user ID 'user' and a password 'pass' for accessing streams from various Ntrip Broadcasters. Replace these account details by a the personal user ID and password you receive following an online registration through <u>http://register.rtcm-ntrip.org</u>. 2724 </p> 2725 <p> 2726 Note that the account for an Ntrip Broadcaster is usually limited to pulling a certain 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. 2678 2727 </p> 2679 2728 <p> … … 2689 2738 <ol type=b> 2690 2739 <li>File 'RinexObs.bnc'<br> 2691 The purpose of this configuration is to convert RTCM streams to RINEX observation files. The configuration pulls streams from several Ntrip broadcasters using differen Ntrip versions and generate 1sec/15min RINEX Version 3 observation files. See <u>http://igs.bkg.bund.de/ntrip/observations</u> for observation stream resources.2740 The purpose of this configuration is to convert RTCM streams to RINEX Observation files. The configuration pulls streams from several Ntrip Broadcasters using differen Ntrip versions and generate 1sec/15min RINEX Version 3 Observation files. See <u>http://igs.bkg.bund.de/ntrip/observations</u> for observation stream resources. 2692 2741 </li> 2693 2742 <br> 2694 2743 <li>File 'RinexEpn.bnc'<br> 2695 The purpose of this configuration is to convert RTCM streams to RINEX navigation files. The configuration pulls an RTCM Version 3 stream carrying Broadcast Ephemeris coming from the real-time EUREF and IGS network. It saves hourly RINEX Version 3 navigation files. See http://igs.bkg.bund.de/ntrip/ephemeris for further real-time Broadcast Ephemeris resources.2744 The purpose of this configuration is to convert RTCM streams to RINEX Navigation files. The configuration pulls an RTCM Version 3 stream carrying Broadcast Ephemeris coming from the real-time EUREF and IGS network. It saves hourly RINEX Version 3 Navigation files. See http://igs.bkg.bund.de/ntrip/ephemeris for further real-time Broadcast Ephemeris resources. 2696 2745 </li> 2697 2746 <br> … … 2709 2758 <br> 2710 2759 <li>File 'FeedEngine.bnc'<br> 2711 The purpose of this configuration is to feed a real-time GNSS engine with observations from a number of remote reference stations. The configuration pulls streams provided in various formats from different Ntrip broadcasters. Incoming observations are decoded, synchronized and output through a local IP port and saved into a file. Failure and recovery thresholds are specified to inform about outages.2760 The purpose of this configuration is to feed a real-time GNSS engine with observations from a number of remote reference stations. The configuration pulls streams provided in various formats from different Ntrip Broadcasters. Incoming observations are decoded, synchronized and output through a local IP port and saved into a file. Failure and recovery thresholds are specified to inform about outages. 2712 2761 </li> 2713 2762 <br> … … 2721 2770 <br> 2722 2771 <li>File 'PPPPostProc.bnc<br> 2723 The purpose of this configuration is Precise Point Positioning in Post Processing mode. BNC reads a RINEX observation and a RINEX Version 3 navigation files and a Broadcast Corrections files. PPP processing otions are set in support of the QuickStart mode. The output is saved in a specific Post Processing logfile and contains the coordinates derived over time following the implemented PPP filter algorithm.2772 The purpose of this configuration is Precise Point Positioning in Post Processing mode. BNC reads a RINEX Observation and a RINEX Version 3 Navigation files and a Broadcast Corrections files. PPP processing otions are set in support of the QuickStart mode. The output is saved in a specific Post Processing logfile and contains the coordinates derived over time following the implemented PPP filter algorithm. 2724 2773 </li> 2725 2774 <br> … … 2733 2782 <br> 2734 2783 <li>File 'Upload.bnc'<br> 2735 The purpose of this configuration is to upload orbits and clocks from a real-time GNSS engine to an Ntrip broadcaster. For that the configuration reads precise orbits and clocks in RTNET format. It also reads a stream carrying Broadcast Ephemeris. BNC converts the orbits and clocks into Broadcast Corrections and encodes them in RTCM Version 3 SSR messages messages to uploads them to an Ntrip broadcaster. The Broadcast Corrections stream is referred to satellite Center of Mass (CoM) and IGS08. Orbits are saved on disk in SP3 format and clocks in clock RINEX format.2784 The purpose of this configuration is to upload orbits and clocks from a real-time GNSS engine to an Ntrip Broadcaster. For that the configuration reads precise orbits and clocks in RTNET format. It also reads a stream carrying Broadcast Ephemeris. BNC converts the orbits and clocks into Broadcast Corrections and encodes them in RTCM Version 3 SSR messages messages to uploads them to an Ntrip Broadcaster. The Broadcast Corrections stream is referred to satellite Center of Mass (CoM) and IGS08. Orbits are saved on disk in SP3 format and clocks in clock RINEX format. 2736 2785 </li> 2737 2786 <br> … … 2741 2790 <br> 2742 2791 <li>File 'Combi.bnc'<br> 2743 The purpose of this configuration is to pulls several streams carrying Broadcast Corrections and a Broadcast Ephemeris stream from an Ntrip broadcaster to produce a combined Broadcast Corrections stream. BNC encodes the combination product in RTCM Version 3 SSR messages and uploads it to an Ntrip broadcaster. The Broadcast Corrections stream is not referred to satellite Center of Mass (CoM). It is referred to IGS08. Orbits are saved in SP3 format and clocks in clock RINEX format.2792 The purpose of this configuration is to pulls several streams carrying Broadcast Corrections and a Broadcast Ephemeris stream from an Ntrip Broadcaster to produce a combined Broadcast Corrections stream. BNC encodes the combination product in RTCM Version 3 SSR messages and uploads it to an Ntrip Broadcaster. The Broadcast Corrections stream is not referred to satellite Center of Mass (CoM). It is referred to IGS08. Orbits are saved in SP3 format and clocks in clock RINEX format. 2744 2793 </li> 2745 2794 <br> … … 2794 2843 <tr><td>corrIntr=1 day</td><td>Broadcast Corrections: Interval</td></tr> 2795 2844 <tr><td>corrPort=</td><td>Broadcast Corrections: Port</td></tr> 2796 <tr><td>corrTime=5</td><td>Broadcast Corrections: Wait for full epoch</td></tr>2845 <tr><td>corrTime=5</td><td>Broadcast Corrections: Wait for full corr epoch</td></tr> 2797 2846 2798 2847 <tr><td>outPort=</td><td>Feed Engine: Port</td></tr> 2799 <tr><td>waitTime=5</td><td>Feed Engine: Wait for full epoch</td></tr>2848 <tr><td>waitTime=5</td><td>Feed Engine: Wait for full obs epoch</td></tr> 2800 2849 <tr><td>binSampl=0</td><td>Feed Engine: Sampling</td></tr> 2801 2850 <tr><td>outFile=</td><td>Feed Engine: File (full path)</td></tr> … … 2913 2962 <ul> 2914 2963 <li>'mountPoints' to change the selection of streams to be processed, see section 'Streams',</li> 2915 <li>'waitTime' to change the 'Wait for full epoch' option, see section 'Feed Engine', and</li>2964 <li>'waitTime' to change the 'Wait for full obs epoch' option, see section 'Feed Engine', and</li> 2916 2965 <li>'binSampl' to change the 'Sampling' option, see section 'Feed Engine'.</li> 2917 2966 </ul>
Note:
See TracChangeset
for help on using the changeset viewer.
