Changeset 338 in ntrip for trunk


Ignore:
Timestamp:
Nov 27, 2006, 1:00:37 PM (18 years ago)
Author:
weber
Message:

* empty log message *

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/BNC/bnchelp.html

    r329 r338  
    2323<br>
    2424
    25 <a name="purpose">
    26 <p><h3>A - Purpose</h3></p>
     25<p><a name="purpose"><h3>A - Purpose</h3></p>
    2726
    2827<p> The purpose of BNC is to
     
    4544BNC 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.
    4645</p>
    47 <p>
    48 <a name="options">
    49 <p><h3>B - Options</h3></p>
     46<p><a name="options"><h3>B - Options</h3></p>
    5047<p>
    5148B - 1. <a href=#file>File</a><br>
     
    7673</p>
    7774
    78 <a name="file">
    79 <p><h4>B - 1. File</h4></p>
     75<p><a name="file"><h4>B - 1. File</h4></p>
    8076
    8177<p>
     
    9591</p>
    9692
    97 <a name="help">
    98 <p><h4>B - 2. Help</h4></p>
     93<p><a name="help"><h4>B - 2. Help</h4></p>
    9994
    10095<p>
     
    112107</p>
    113108
    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>
    116110
    117111<p>
     
    121115</p>
    122116
    123 <a name="output"> <p><h4>B - 4. Synchronized Output</h4></p>
     117<p><a name="output"><h4>B - 4. Synchronized Output</h4></p>
    124118<p>
    125119BNC 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>
     
    129123In case an observation is unavailable, its value is set to zero '0.000'.
    130124</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>
    133126<p>
    134127When 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.
     
    138131</p>
    139132
    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>
    142134<p>
    143135Enter 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.
    144136</p>
    145137
    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>
    148139<p>
    149140BNC 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>
     
    182173</pre>
    183174
    184 <a name="rinex">
    185 <p><h4>B - 5. RINEX</h4></p>
     175<p><a name="rinex"><h4>B - 5. RINEX</h4></p>
    186176<p>
    187177Observations 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>
     
    217207</p>
    218208
    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>
    221210<p>
    222211Enter 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.
    223212</p>
    224213
    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>
    227215<p>
    228216Whenever 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).
    229217</p>
    230218
    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>
    233220<p>
    234221Select the interval for the RINEX file generation. Default for 'RINEX file interval' is 15 minutes.
    235222</p>
    236223
    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>
    239225<p>
    240226Select the RINEX sample interval in seconds. Zero '0' stands for converting all incoming epochs to RINEX. Default for RINEX 'Sampling' is '0'.
    241227</p>
    242228
    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>
    245230<p>
    246231Whenever 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.
     
    293278<p>
    294279
    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>
    297281<p>
    298282When 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.
    299283</p>
    300284
    301 <a name="mountpoints">
    302 <p><h4>B - 6. Mountpoints</h4></p>
     285<p><a name="mountpoints"><h4>B - 6. Mountpoints</h4></p>
    303286<p>
    304287Each 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.
    305288</p>
    306289
    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>
    309291<p>
    310292Button 'Add Mountpoints' opens a window that allows you to select data streams from an NTRIP broadcaster by their mountpoints.
    311293</p>
    312294
    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>
    315296<p>
    316297Enter 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>.
    317298</p>
    318299
    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>
    321301<p>
    322302Streams 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>.
    323303</p>
    324304
    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>
    327306<p>
    328307Hit 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.
     
    332311</p>
    333312
    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>
    336314<p>
    337315To 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>
    338316
    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>
    341318<p>
    342319BNC 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'.
    343320</p>
    344321
    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>
    347323<p>
    348324BNC 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.
    349325</p>
    350326
    351 <a name="start">
    352 <p><h4>B - 8. Start</h4></p>
     327<p><a name="start"><h4>B - 8. Start</h4></p>
    353328<p>
    354329Hit '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.
    355330</p>
    356331
    357 <a name="stop">
    358 <p><h4>B - 9. Stop</h4></p>
     332<p><a name="stop"><h4>B - 9. Stop</h4></p>
    359333<p>
    360334Hit the 'Stop' button in order to stop BNC.
    361335</p>
    362336
    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>
    365338<p>
    366339You 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).
     
    370343</p>
    371344<br>
    372 <a name="limits">
    373 <p><h3>C - Limitations</h3></p>
     345<p><a name="limits"><h3>C - Limitations</h3></p>
    374346<ul>
    375347<li>
     
    407379<br>
    408380</ul>
    409 <a name="authors">
    410 <p><h3>D - Authors</h3></p>
     381<p><a name="authors"><h3>D - Authors</h3></p>
    411382<p>
    412383The 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:
     
    414385<li> RTCM 2.x decoder, written by Oliver Montenbruck, German Space Operations Center, DLR, Oberpfaffenhofen, with contributions from Leos Mervart</li>
    415386<li> RTCM 3 decoder, written for BKG by Dirk Stoecker, Euronik GmbH, Schoenefeld</li>
    416 <li> RTIGS decoder, written by Ken MacLeod, National Resources, Canada.</li>
     387<li> RTIGS decoder, written by Ken MacLeod, Natural Resources, Canada.</li>
    417388</ul>
    418389</p>
     
    428399<br>
    429400
    430 <a name="links">
    431 <p><h3>E - Links</h3></p>
     401<p><a name="links"><h3>E - Links</h3></p>
    432402<table>
    433403<tr></tr>
     
    441411<br>
    442412
    443 <a name="annex">
    444 <p><h3>F - Annex</h3></p>
     413<p><a name="annex"><h3>F - Annex</h3></p>
    445414<p>
    446415F - 1. <a href=#ntrip>NTRIP</a><br>
     
    454423<br>
    455424
    456 <a name="ntrip">
    457 <p><h4>F - 1. NTRIP</h4></p>
     425<p><a name="ntrip"><h4>F - 1. NTRIP</h4></p>
    458426
    459427<p>
     
    480448</p>
    481449
    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>
    484451
    485452<p>
     
    497464</p>
    498465
    499 <a name="rtcm">
    500 <p><h4>F - 2. RTCM</h4></p>
     466<p><a name="rtcm"><h4>F - 2. RTCM</h4></p>
    501467
    502468<p>
     
    507473<br>
    508474
    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>
    511476<p>
    512477Transmitting 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.
     
    540505</ul>
    541506
    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>
    544508<p>
    545509RTCM 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.
     
    569533</ul>
    570534
    571 <a name="rtigs">
    572 <p><h4>F - 3. RTIGS</h4></p>
     535<p><a name="rtigs"><h4>F - 3. RTIGS</h4></p>
    573536<p>
    574537RTIGS 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:
     
    623586</p>
    624587
    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>
    627589<p>
    628590The 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.