begEpoch -begObs +begObs Observation -begObs +begObs Observation -begObs +begObs Observation ... @@ -283,4 +284,12 @@ ++
B - 5.7 Approx. Lat./Lon. - mandatory for Virtual Reference Stations (VRS)
+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). +
++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. +
+@@ -375,5 +384,5 @@
-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'. +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'.
@@ -510,5 +519,5 @@
-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. +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.
@@ -570,6 +579,6 @@