Index: /trunk/BNC/bnchelp.html
===================================================================
--- /trunk/BNC/bnchelp.html	(revision 358)
+++ /trunk/BNC/bnchelp.html	(revision 359)
@@ -60,4 +60,5 @@
 &nbsp; &nbsp; &nbsp; B - 5.5. <a href=#rnxskeleton>RINEX Skeleton Extension</a><br>
 &nbsp; &nbsp; &nbsp; B - 5.6. <a href=#rnxappend>Append Files</a><br>
+&nbsp; &nbsp; &nbsp; B - 5.7. <a href=#approxlatlon>Approx. Lat./Lon.</a><br>
 B - 6. <a href=#mountpoints>Mountpoints</a><br>
 &nbsp; &nbsp; &nbsp; B - 6.1. <a href=#AddMounts>Add Mountpoints</a><br>
@@ -142,9 +143,9 @@
 <pre>
 begEpoch
-begObs  
+begObs
 Observation
-begObs  
+begObs
 Observation
-begObs  
+begObs
 Observation
 ...
@@ -283,4 +284,12 @@
 </p> 
 
+<p><a name="approxlatlon"><h4>B - 5.7 Approx. Lat./Lon. - mandatory for Virtual Reference Stations (VRS)</h4></p>
+<p>
+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).
+</p>
+<p>
+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.
+</p> 
+
 <p><a name="mountpoints"><h4>B - 6. Mountpoints</h4></p>
 <p>
@@ -375,5 +384,5 @@
 </li>
 <li>
-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.
+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.
 </li>
 <li>
@@ -458,5 +467,5 @@
 
 <p>
-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'.
 </p>
 <p>
@@ -510,5 +519,5 @@
 <p><a name="rtcm3"><h4>F - 2.2 RTCM Version 3</h4></p>
 <p>
-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.
 </p>
 <p>
@@ -570,6 +579,6 @@
 <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>
 <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>
-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>
-<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>
+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>
+<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>
 </ul>
 <p>
