Changeset 7608 in ntrip for trunk/BNC

Timestamp:

Dec 7, 2015, 4:22:02 PM (8 years ago)

Author:

weber

Message:

Documentation completed

File:

• trunk/BNC/src/bnchelp.html (modified) (2 diffs)

trunk/BNC/src/bnchelp.html

@@ -900 +900 @@
 </p>
 <p>
-To cope with an increasing number of transmitting GNSS reference stations, the Federal Agency for Cartography and Geodesy (BKG) together with the Informatik Centrum Dortmund (ICD) in Germany developed a streaming protocol for satellite navigation data called 'Networked Transport of RTCM via Internet Protocol' (Ntrip). The protocol was built on top of the HTTP standard and included the provision of meta data describing the stream contents. Any stream could now be globally transmitted over just one IP port: HTTP port 80. Stream availability and content details became part of the transport protocol. The concept was first published in 2003 (Weber et al. 2003) and based on three software components, namely an NtripServer pushing data from a reference station to an NtripCaster and an NtripClient pulling data from the stream splitting caster to support a rover receiver. (Note that from a socket-programmers perspective NtripServer and NtripClient both act as clients; only the NtripCaster operates as socket-server.) Ntrip could essentially benefit from Internet Radio developments. It was the ICECAST mulitmedia server which provided the bases for BKG's 'Professional Ntrip Broadcaster' with software published first in 2003 and of course again as Open Source under GPL.
+To cope with an increasing number of transmitting GNSS reference stations, the Federal Agency for Cartography and Geodesy (BKG) together with the Informatik Centrum Dortmund (ICD) in Germany developed a streaming protocol for satellite navigation data called 'Networked Transport of RTCM via Internet Protocol' (Ntrip). The protocol was built on top of the HTTP standard and included the provision of meta data describing the stream contents. Any stream could now be globally transmitted over just one IP port: HTTP port 80. Stream availability and content details became part of the transport protocol. The concept was first published in 2003 (Weber et al. 2003) and based on three software components, namely an NtripServer pushing data from a reference station to an NtripCaster and an NtripClient pulling data from the stream splitting caster to support a rover receiver. (Note that from a socket-programmers perspective NtripServer and NtripClient both act as clients; only the NtripCaster operates as socket-server.) Ntrip could essentially benefit from Internet Radio developments. It was the ICECAST multimedia server which provided the bases for BKG's 'Professional Ntrip Broadcaster' with software published first in 2003 and of course again as Open Source under GPL.
 </p>
 <p>
@@ -909 +909 @@
 </p>
 <p>
-Implementing some post processing capability is essential for debugging real-time software in case of probelms. So gradually certain real-time options of BNC had to be complemented to work offline with reading data from files. Moreover, beginning in 2012 the software was extended to support Galileo, BeiDou, and QZSS besides GPS and GLONASS. With that the Open Source tool BNC could be used for RINEX Version 3 file editing, concatenation and quality checks, a post processing functionallity eagerly demanded by the IGS Multi-GNSS Experiment and not really covered at that time by UNAVCO's famous TEQC program because of its focus on GPS.
+Adding real-time Precise Point Positioning (PPP) support to BNC began in 2010 as an important completion in view of developing an Open RTCM Standard for that. According to the State Space Representation (SSR) model, new Version 3 messages are proposed to provide e.g. satellite orbit and clock corrections and ionospheric corrections as well as biases for code and phase data. The ultimate goal for SSR standardization is to reach centimeter level accuracy within seconds as an alternative to Network RTK methods like VRS, FKP, and MAC. Because of interoperability aspects, an Open Standard in this area is of particular interest for clients. Regarding stand-alone PPP in BNC it is worth mentioning that the program is not and can never be in competition with a receiver manufacturer's proprietary solution. Only software or services which are part of a receiver firmware could have the potential of becoming a thread for commercial interests. However, implementing or not implementing an Open PPP approach in a firmware is and always remains a manufacturer's decision.
+</p>
+<p>
+Implementing some post processing capability is essential for debugging real-time software in case of problems. So certain real-time options in BNC were complemented to work offline through reading data from files. Moreover, beginning in 2012 the software was extended to support Galileo, BeiDou, and QZSS besides GPS and GLONASS. With that the Open Source tool BNC could be used for RINEX Version 3 file editing, concatenation and quality checks, a post processing functionality demanded by the IGS Multi-GNSS Experiment and not really covered at that time by UNAVCO's famous TEQC program with its limitation on GPS.
+</p>
+<p>
+In summary we can say that BNC and its publication under GNU GPL is primarily thought to be well-suited for test, validation and demonstration of new approaches in precise satellite navigation when IP streaming is involved. Commissioned by a governmental agency, the overall intention has always been to push the further development of RTCM Recommended Standards to the benefit of the general public.
 </p>