Changeset 359 in ntrip
- Timestamp:
- Dec 22, 2006, 1:38:58 PM (17 years ago)
- File:
-
- 1 edited
-
trunk/BNC/bnchelp.html (modified) (7 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/BNC/bnchelp.html
r345 r359 60 60 B - 5.5. <a href=#rnxskeleton>RINEX Skeleton Extension</a><br> 61 61 B - 5.6. <a href=#rnxappend>Append Files</a><br> 62 B - 5.7. <a href=#approxlatlon>Approx. Lat./Lon.</a><br> 62 63 B - 6. <a href=#mountpoints>Mountpoints</a><br> 63 64 B - 6.1. <a href=#AddMounts>Add Mountpoints</a><br> … … 142 143 <pre> 143 144 begEpoch 144 begObs 145 begObs 145 146 Observation 146 begObs 147 begObs 147 148 Observation 148 begObs 149 begObs 149 150 Observation 150 151 ... … … 283 284 </p> 284 285 286 <p><a name="approxlatlon"><h4>B - 5.7 Approx. Lat./Lon. - mandatory for Virtual Reference Stations (VRS)</h4></p> 287 <p> 288 BNC allows to retrieve streams from Virtual Reference Stations (VRS). For that an approximate rover position needs to be send in NMEA format to a VRS supporting NTRIP broadcaster. In return, an individual user-specific data stream is generated by a network RTK software. This stream is tailored exactly to the 'Approx. Lat./Lon.' you enter. The approximate position has to be introduced in northern latitude degrees (example for northern hemisphere: 52.436, example for eastern hemisphere: -24.567) and eastern longitude degrees (example: 358.872 or -1.128). 289 </p> 290 <p> 291 Introducing an 'Approx. Lat./Lon.' is only necessary when retrieving a VRS stream. The approximate position must point to a location within the service area of the affected RTK network. Note that VRS streams that require an 'Approx. Lat./Lon.' are marked by the integer '1' in data field 'nmea' of the affected NTRIP broadcaster source-table. Note further that when working in a Local Area Network (LAN), NMEA messages may be blocked by a proxy server, firewall or virus scanner. 292 </p> 293 285 294 <p><a name="mountpoints"><h4>B - 6. Mountpoints</h4></p> 286 295 <p> … … 375 384 </li> 376 385 <li> 377 EUREF as well as IGS follow an open data policy. Streams are made available through NTRIP broadcasters at <u>www.euref-ip.net</u> and <u>www.igs-ip.net</u> free of charge to anyone for any purpose. Up to now it is not clear how many users will have to be supported simultaneously. The given situation may develop in a way that becomes difficult to serve all registered users at all times. 386 EUREF as well as IGS follow an open data policy. Streams are made available through NTRIP broadcasters at <u>www.euref-ip.net</u> and <u>www.igs-ip.net</u> free of charge to anyone for any purpose. Up to now it is not clear how many users will have to be supported simultaneously. The given situation may develop in a way that becomes difficult to serve all registered users at all times. In case limited dissemination resources on the NTRIP broadcaster side (software restrictions, bandwidth limitation etc.) make it necessary, first priority in stream provision will be given to stream providers, re-broadcasting activities, and real-time analysis centers while access for others might be temporarily denied. 378 387 </li> 379 388 <li> … … 458 467 459 468 <p> 460 Source-table records of type STR contain the following data fields: 'mountpoint', 'identifier', 'format', 'format-details', 'carrier', 'nav-system', 'network', 'country','latitude', 'longitude', 'nmea', 'solution', 'generator', 'compr-encryp', 'authentication', 'fee', 'bitrate', 'misc'.469 Source-table records of type STR contain the following data fields: 'mountpoint', 'identifier', 'format', 'format-details', 'carrier', 'nav-system', 'network', 'country', 'latitude', 'longitude', 'nmea', 'solution', 'generator', 'compr-encryp', 'authentication', 'fee', 'bitrate', 'misc'. 461 470 </p> 462 471 <p> … … 510 519 <p><a name="rtcm3"><h4>F - 2.2 RTCM Version 3</h4></p> 511 520 <p> 512 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.521 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. 513 522 </p> 514 523 <p> … … 570 579 <li>An observation message is output once per second. The header is 12 bytes long and the SOC data is 21 bytes per PRN. So a typical RTIGSO_T message will be 390 bytes if 8 sats are being tracked.</li> 571 580 <li>An ephemeris message is output when the ephemeris is decoded by the GPS receiver. The time in the Ephemeris header is the collected time. Only one ephemeris can be bundled in a RTIGSE_T message.<br> 572 A RTIGSE_T message contains one eph. The 573 <li>The RTIGSM_T 581 A RTIGSE_T message contains one eph. The message consists of 12 header bytes and 72 ephemeris bytes, for a total of 84 bytes.</li> 582 <li>The RTIGSM_T (met) message should be issued once every 15 minutes. A basic met message consists of a 12 byte header and 3 longs (temp, press and relative humidity) for a total of 24 bytes.</li> 574 583 </ul> 575 584 <p>
Note:
See TracChangeset
for help on using the changeset viewer.
