- Timestamp:
- Nov 27, 2006, 1:00:37 PM (18 years ago)
- File:
-
- 1 edited
-
trunk/BNC/bnchelp.html (modified) (24 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/BNC/bnchelp.html
r329 r338 23 23 <br> 24 24 25 <a name="purpose"> 26 <p><h3>A - Purpose</h3></p> 25 <p><a name="purpose"><h3>A - Purpose</h3></p> 27 26 28 27 <p> The purpose of BNC is to … … 45 44 BNC needs access to the Internet with a minimum of about 2 to 6 kbits/second per stream depending on the stream format. You need to make sure that you have always the necessary bandwidth available. BNC has the capacity to retrieve hundreds of GNSS data streams simultaneously. Please be aware that it is a powerful tool that may generate a heavy workload on the NTRIP broadcaster side depending on the number of streams it requests. We suggest to limited the number of streams where possible to avoid unnecessary workload. 46 45 </p> 47 <p> 48 <a name="options"> 49 <p><h3>B - Options</h3></p> 46 <p><a name="options"><h3>B - Options</h3></p> 50 47 <p> 51 48 B - 1. <a href=#file>File</a><br> … … 76 73 </p> 77 74 78 <a name="file"> 79 <p><h4>B - 1. File</h4></p> 75 <p><a name="file"><h4>B - 1. File</h4></p> 80 76 81 77 <p> … … 95 91 </p> 96 92 97 <a name="help"> 98 <p><h4>B - 2. Help</h4></p> 93 <p><a name="help"><h4>B - 2. Help</h4></p> 99 94 100 95 <p> … … 112 107 </p> 113 108 114 <a name="proxy"> 115 <p><h4>B - 3. Proxy - mandatory if BNC is operated in a protected LAN</h4></p> 109 <p><a name="proxy"><h4>B - 3. Proxy - mandatory if BNC is operated in a protected LAN</h4></p> 116 110 117 111 <p> … … 121 115 </p> 122 116 123 < a name="output"> <p><h4>B - 4. Synchronized Output</h4></p>117 <p><a name="output"><h4>B - 4. Synchronized Output</h4></p> 124 118 <p> 125 119 BNC lets you output synchronized observations epoch by epoch. This output is made available in a plain ASCII format and in a binary format. The output comprises the following observations if available:</p> … … 129 123 In case an observation is unavailable, its value is set to zero '0.000'. 130 124 </p> 131 <a name="wait"> 132 <p><h4>B - 4.1 Wait for Full Epoch - optional</h4></p> 125 <p><a name="wait"><h4>B - 4.1 Wait for Full Epoch - optional</h4></p> 133 126 <p> 134 127 When feeding a real-time GNSS engine waiting for input epoch by epoch, BNC ignores 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 you would accept for your real-time GNSS product. Default value for 'Wait for full epoch' is 1 second. … … 138 131 </p> 139 132 140 <a name="ascii"> 141 <p><h4>B - 4.2 ASCII Output File - optional</h4></p> 133 <p><a name="ascii"><h4>B - 4.2 ASCII Output File - optional</h4></p> 142 134 <p> 143 135 Enter the full path for a file to save synchronized observations in a plain ASCII format. Default value is an empty option field, meaning that no ASCII output file is created. 144 136 </p> 145 137 146 <a name="binary"> 147 <p><h4>B - 4.3 Port for Binary Output - optional</h4></p> 138 <p><a name="binary"><h4>B - 4.3 Port for Binary Output - optional</h4></p> 148 139 <p> 149 140 BNC makes synchronized observations available in a binary format on your local host (IP 127.0.0.1) through an IP port. Enter an IP port number to activate this function. Default is an empty option field, meaning that no binary output is generated.</p> … … 182 173 </pre> 183 174 184 <a name="rinex"> 185 <p><h4>B - 5. RINEX</h4></p> 175 <p><a name="rinex"><h4>B - 5. RINEX</h4></p> 186 176 <p> 187 177 Observations are converted to RINEX Version 2.1. RINEX file names are derived by BNC from the first 4 characters of the corresponding mountpoint (4Char Station ID) while omitting the residual part of the mountpoint string. Thus, retrieving data from mountpoints FRANKFURT and WETTZELL leads to hourly RINEX observation files named</p> … … 217 207 </p> 218 208 219 <a name="rnxpath"> 220 <p><h4>B - 5.1 RINEX Directory - optional</h4></p> 209 <p><a name="rnxpath"><h4>B - 5.1 RINEX Directory - optional</h4></p> 221 210 <p> 222 211 Enter a path for saving the RINEX files in a directory. If this directory does not exist, BNC will not create RINEX files. Default value for 'RINEX directory' is an empty option field, meaning that streams are not converted to RINEX. 223 212 </p> 224 213 225 <a name="rnxscript"> 226 <p><h4>B - 5.2 RINEX Script - optional</h4></p> 214 <p><a name="rnxscript"><h4>B - 5.2 RINEX Script - optional</h4></p> 227 215 <p> 228 216 Whenever a RINEX file is saved, you may like to compress, copy or upload it immediately via FTP. For that you enter the full path of a script or batch file carrying out these operations. The RINEX file path will be passed to the script as a command line parameter (%1 on Windows systems, $1 on Unix/Linux systems). 229 217 </p> 230 218 231 <a name="rnxinterval"> 232 <p><h4>B - 5.3 RINEX File Interval - mandatory if 'RINEX directory' set</h4></p> 219 <p><a name="rnxinterval"><h4>B - 5.3 RINEX File Interval - mandatory if 'RINEX directory' set</h4></p> 233 220 <p> 234 221 Select the interval for the RINEX file generation. Default for 'RINEX file interval' is 15 minutes. 235 222 </p> 236 223 237 <a name="rnxsample"> 238 <p><h4>B - 5.4 RINEX Sampling - mandatory if 'RINEX directory' set </h4></p> 224 <p><a name="rnxsample"><h4>B - 5.4 RINEX Sampling - mandatory if 'RINEX directory' set </h4></p> 239 225 <p> 240 226 Select the RINEX sample interval in seconds. Zero '0' stands for converting all incoming epochs to RINEX. Default for RINEX 'Sampling' is '0'. 241 227 </p> 242 228 243 <a name="rnxskeleton"> 244 <p><h4>B - 5.5 RINEX Skeleton Extension - optional</h4></p> 229 <p><a name="rnxskeleton"><h4>B - 5.5 RINEX Skeleton Extension - optional</h4></p> 245 230 <p> 246 231 Whenever BNC generates a new RINEX file, it first tries to retrieve information needed for RINEX headers from so-called public RINEX header skeleton files which are derived from sitelogs. An HTTP 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 for a public RINEX header skeleton file concerning the EPN station Brussels. … … 293 278 <p> 294 279 295 <a name="rnxappend"> 296 <p><h4>B - 5.6 Append Files</h4></p> 280 <p><a name="rnxappend"><h4>B - 5.6 Append Files</h4></p> 297 281 <p> 298 282 When starting BNC, new RINEX files are created by default. Probably existing files will be overwritten. However, it may be desirable to append observations to already existing RINEX files following a restart of BNC after an intentional 'Stop', a system crash or a crash of BNC. Hit 'Append files' to continue with already existing files and thus save what has been recorded so far. Note that the option 'Append files' also concerns the 'ASCII output file' and the 'Log' file. 299 283 </p> 300 284 301 <a name="mountpoints"> 302 <p><h4>B - 6. Mountpoints</h4></p> 285 <p><a name="mountpoints"><h4>B - 6. Mountpoints</h4></p> 303 286 <p> 304 287 Each stream on an NTRIP broadcaster is defined through a unique source ID called mountpoint. An NTRIP client like BNC can access the data of a desired stream by its mountpoint. Information about 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. 305 288 </p> 306 289 307 <a name="AddMounts"> 308 <p><h4>B - 6.1 Add Mountpoints</h4></p> 290 <p><a name="AddMounts"><h4>B - 6.1 Add Mountpoints</h4></p> 309 291 <p> 310 292 Button 'Add Mountpoints' opens a window that allows you to select data streams from an NTRIP broadcaster by their mountpoints. 311 293 </p> 312 294 313 <a name="HostPort"> 314 <p><h4>B - 6.2 Broadcaster Host and Port - mandatory</h4></p> 295 <p><a name="HostPort"><h4>B - 6.2 Broadcaster Host and Port - mandatory</h4></p> 315 296 <p> 316 297 Enter the NTRIP broadcaster host IP and port number. <u>http://www.rtcm-ntrip.org/home</u> provides information about known NTRIP broadcaster installations. 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>. 317 298 </p> 318 299 319 <a name="account"> 320 <p><h4>B - 6.3 Broadcaster User and Password - mandatory for protected streams</h4></p> 300 <p><a name="account"><h4>B - 6.3 Broadcaster User and Password - mandatory for protected streams</h4></p> 321 301 <p> 322 302 Streams on NTRIP broadcasters might be protected by password. Enter a valid 'User' ID and 'Password' for access to protected NTRIP broadcaster streams. Accounts are usually provided per NTRIP broadcaster through a registration procedure. Register through <u>http://igs.bkg.bund.de/index_ntrip_reg.htm</u> for access to protected streams on <u>www.euref-ip.net</u> and <u>www.igs-ip.net</u>. 323 303 </p> 324 304 325 <a name="GetTable"> 326 <p><h4>B - 6.4 Get Table</h4></p> 305 <p><a name="GetTable"><h4>B - 6.4 Get Table</h4></p> 327 306 <p> 328 307 Hit button 'Get Table' to download the source-table from the NTRIP broadcaster. Please pay attention to data fields 'format' and 'format-details'. Keep in mind that BNC can only decode and convert streams that come in RTCM 2.x, RTCM 3, or RTIGS formats. RTCM 2.x streams must contain message types 18 and 19 while RTCM 3 streams must contain message types 1001 or 1003, better 1003 or 1004 (GPS), 1009 or 1010, even better 1011 or 1012 (GLONASS), see data field 'format-details' for available message types and their repetition rates in brackets. Select your streams line by line, use +Shift and +Ctrl when necessary. … … 332 311 </p> 333 312 334 <a name="delete"> 335 <p><h4>B - 6.5 Delete Mountpoints</h4></p> 313 <p><a name="delete"><h4>B - 6.5 Delete Mountpoints</h4></p> 336 314 <p> 337 315 To delete a stream shown under 'Mountpoints' in the main window, select it by mouse click and hit 'Delete Mountpoints'. For a simultaneous deletion of several streams highlight them using +Shift and +Ctrl.</p> 338 316 339 <a name="edit"> 340 <p><h4>B - 6.6 Edit Mountpoints</h4></p> 317 <p><a name="edit"><h4>B - 6.6 Edit Mountpoints</h4></p> 341 318 <p> 342 319 BNC automatically selects one out of several incorporated decoders for a stream based on its 'format' and 'format-details' as given in the source-table. It may happen that you need to overrule the automated decoder selection because of source-table setup deficiencies. Therefore BNC allows to edit (double-click) the decoder string for each stream shown under 'Mountpoints'. Accepted decoder strings allowed to be introduced are 'RTCM_2.x', 'RTCM_3', and 'RTIGS'. 343 320 </p> 344 321 345 <a name="log"> 346 <p><h4>B - 7. Log - optional</h4></p> 322 <p><a name="log"><h4>B - 7. Log - optional</h4></p> 347 323 <p> 348 324 BNC comments its activities in the 'Log' section on the main windows. Comments can be saved in a file when entering a full path for 'Log' file. Information is given on the communication between BNC and the NTRIP broadcaster as well as on problems that may occur concerning communication link, stream availability, stream delay, stream conversion etc. Default value for 'Log' is an empty option field, meaning that BNC comments are not saved in a file. 349 325 </p> 350 326 351 <a name="start"> 352 <p><h4>B - 8. Start</h4></p> 327 <p><a name="start"><h4>B - 8. Start</h4></p> 353 328 <p> 354 329 Hit 'Start' to start retrieving, decoding, and converting GNSS data streams in real-time. Note that 'Start' generally forces BNC to begin with fresh RINEX files and thus overwrite probably existing files when necessary unless option 'Append files' is set. 355 330 </p> 356 331 357 <a name="stop"> 358 <p><h4>B - 9. Stop</h4></p> 332 <p><a name="stop"><h4>B - 9. Stop</h4></p> 359 333 <p> 360 334 Hit the 'Stop' button in order to stop BNC. 361 335 </p> 362 336 363 <a name="nw"> 364 <p><h4>B - 10. No Window - optional</h4></p> 337 <p><a name="nw"><h4>B - 10. No Window - optional</h4></p> 365 338 <p> 366 339 You can use BNC on all systems in batch mode with the command line option -nw. BNC then runs in 'no window' mode, reading options from the configuration file ${HOME}/.config/BKG/BNC_NTRIP_Client.conf (Unix/Linux) or from the register BKC_NTRIP_Client (Windows). … … 370 343 </p> 371 344 <br> 372 <a name="limits"> 373 <p><h3>C - Limitations</h3></p> 345 <p><a name="limits"><h3>C - Limitations</h3></p> 374 346 <ul> 375 347 <li> … … 407 379 <br> 408 380 </ul> 409 <a name="authors"> 410 <p><h3>D - Authors</h3></p> 381 <p><a name="authors"><h3>D - Authors</h3></p> 411 382 <p> 412 383 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 Advanced Geodesy. BNC integrates the following GNU GPL software components: … … 414 385 <li> RTCM 2.x decoder, written by Oliver Montenbruck, German Space Operations Center, DLR, Oberpfaffenhofen, with contributions from Leos Mervart</li> 415 386 <li> RTCM 3 decoder, written for BKG by Dirk Stoecker, Euronik GmbH, Schoenefeld</li> 416 <li> RTIGS decoder, written by Ken MacLeod, Nat ional Resources, Canada.</li>387 <li> RTIGS decoder, written by Ken MacLeod, Natural Resources, Canada.</li> 417 388 </ul> 418 389 </p> … … 428 399 <br> 429 400 430 <a name="links"> 431 <p><h3>E - Links</h3></p> 401 <p><a name="links"><h3>E - Links</h3></p> 432 402 <table> 433 403 <tr></tr> … … 441 411 <br> 442 412 443 <a name="annex"> 444 <p><h3>F - Annex</h3></p> 413 <p><a name="annex"><h3>F - Annex</h3></p> 445 414 <p> 446 415 F - 1. <a href=#ntrip>NTRIP</a><br> … … 454 423 <br> 455 424 456 <a name="ntrip"> 457 <p><h4>F - 1. NTRIP</h4></p> 425 <p><a name="ntrip"><h4>F - 1. NTRIP</h4></p> 458 426 459 427 <p> … … 480 448 </p> 481 449 482 <a name="source"> 483 <p><h4>F - 1.1 Source-table</h4></p> 450 <p><a name="source"><h4>F - 1.1 Source-table</h4></p> 484 451 485 452 <p> … … 497 464 </p> 498 465 499 <a name="rtcm"> 500 <p><h4>F - 2. RTCM</h4></p> 466 <p><a name="rtcm"><h4>F - 2. RTCM</h4></p> 501 467 502 468 <p> … … 507 473 <br> 508 474 509 <a name="rtcm2"> 510 <p><h4>F - 2.1 RTCM Version 2.x</h4></p> 475 <p><a name="rtcm2"><h4>F - 2.1 RTCM Version 2.x</h4></p> 511 476 <p> 512 477 Transmitting GNSS carrier phase data can be done through RTCM Version 2.x messages. Please note that only RTCM Version 2.3 streams may include GLONASS data. Messages that may be of interest here are of type 1, 2, 3, 6, 9, 16,18/19, 20/21, and 22. … … 540 505 </ul> 541 506 542 <a name="rtcm3"> 543 <p><h4>F - 2.2 RTCM Version 3</h4></p> 507 <p><a name="rtcm3"><h4>F - 2.2 RTCM Version 3</h4></p> 544 508 <p> 545 509 RTCM Version 3 has been developed as a more efficient alternative to RTCM 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 standard is intended to correct these weaknesses. … … 569 533 </ul> 570 534 571 <a name="rtigs"> 572 <p><h4>F - 3. RTIGS</h4></p> 535 <p><a name="rtigs"><h4>F - 3. RTIGS</h4></p> 573 536 <p> 574 537 RTIGS stands for a data format and transport protocol for GPS observations (no GLONASS). It was defined by the Real-Time IGS Working Group (RTIGS WG). Its definition is based on the SOC format. Every RTIGS record has one of the following numbers: … … 623 586 </p> 624 587 625 <a name="soc"> 626 <p><h4>F - 3.1 SOC</h4></p> 588 <p><a name="soc"><h4>F - 3.1 SOC</h4></p> 627 589 <p> 628 590 The SOC format has been designed in July 1999 by the Jet Propulsion Laboratory (JPL) and the California Institute of Technology (CalTech) to transport 1Hz GPS data (no GLONASS) with minimal bandwidth over the open Internet. SOC follows the 'little-endian' byte order meaning that the low-order byte of a number is stored in memory at the lowest address, and the high-order byte at the highest address. Because the transport layer is UDP, the format does not include sync bits, a checksum, or cyclic redundancy checksum (CRC). SOC allows to transport the GPS observable CA, P1, P2, L1, and L2, efficiently compressed down to 14 bytes with 1 mm range resolution and 0.02 mm phase resolution. SOC contains epochs for cycle slips, a stand-alone time-tag per epoch, a minimum representation of the receiver's clock solution, 3 SNR numbers, a unique site id, a modulo 12 hour sequence number and flags for receiver type and GPS health. SOC's simple structure comprises an 8 byte header, a 9 byte overhead for timetag, number of gps, etc., plus 21 data bytes per gps.
Note:
See TracChangeset
for help on using the changeset viewer.
