Changeset 7604 in ntrip for trunk/BNC/src/bnchelp.html


Ignore:
Timestamp:
Dec 6, 2015, 11:04:28 AM (8 years ago)
Author:
weber
Message:

Documentation completed

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/BNC/src/bnchelp.html

    r7603 r7604  
    355355</p>
    356356
    357 <p> BNC has the following capabilities:
     357<p> BNC was designed to serve the following purposes:
    358358<ul>
    359359<li>Retrieve real-time GNSS data streams available through Ntrip transport protocol;</li>
     
    378378<li>Plot positions derived via PPP from RTCM streams or RINEX files on maps from Google Map or OpenStreetMap;</li>
    379379<li>Simultaneously process several Broadcast Correction streams to produce, encode and upload combined Broadcast Corrections;</li>
     380
     381<li>Estimate real-time tropospheric zenith path delays and save them in SINEX troposphere file format;</li>
     382
    380383<li>Read GNSS orbits and clocks in a plain ASCII format from an IP port. They can be produced by a real-time GNSS engine such as RTNET and should be referenced to the IGS Earth-Centered-Earth-Fixed (ECEF) reference system. BNC will then</li>
    381384<ul>
     
    403406</ul>
    404407</p>
     408
    405409<p>
    406410Note that BNC allows to by-pass decoding and conversion algorithms for incoming streams, leave whatever is received untouched to save it in files or output it through local TCP/IP port.
     411</p>
     412
     413<p>
     414BNC supports the following GNSS file formats:
     415</p>
     416<p>
     417<ul>
     418<li>RINEX Version 2.11 & 3.02, Receiver Independent Exchange format for observations, navigation and meteorological data;</li>
     419<li>SINEX Version 2.10, Solution Independent Exchange format for station position and velocity solutions;</li>
     420<li>SINEX TRO, Troposphere Solution Independent Exchange format for zenith path delay products;</li>
     421<li>SP3 Version c format for orbit solutions;</li>
     422<li>Clock RINEX Version 3.02 format for station and satellite clock solutions;</li>
     423<li>ANTEX Version 1.4, Antenna Exchange format for antenna calibration data;</li>
     424<li>NMEA Version 0813, National Marine Electronics Association format for satellinte navigation data;</li>
     425</ul>
    407426</p>
    408427
     
    883902
    884903<p>
    885 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 a 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.
     904To 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 splitter 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.
    886905</p>
    887906
Note: See TracChangeset for help on using the changeset viewer.