This article (and those that it links to) serves to provide a high level summary of the major functions of the SNIP tool.
Some Basic NTRIP Concepts
NTRIP is the primary means by which you connect your correction sources to your moving rover devices, i.e. the GNSS system you are concerned with. An NTRIP Caster acts as the server element for one or more rovers, sending them data as they connect. You still need corrections (from a reference station) and you still need the rover GNSS to use them. And the span/cost of these devices can range from many tens of thousands of dollars for professional grade L1/L2 items, to only a few hundred for low cost L1 OEM boards. In all cases, a good antenna is essential for good results. This is most often depicted in a now classical image of the major NTRIP elements and the data flows:
For a short overview of NTRIP and how it is used, see this article as well.
Some Basic SNIP Concepts
SNIP (also called “simple NTRIP” in some documentation) is a classic NTRIP Caster. Its primary job is to take in-bound “streams” of data and distribute this data to the NTRIP Clients that connect to it. Once set up, there is little to see and for the most part it simply and quietly does its job 24/7 in the background.
There are however a few special features that make SNIP unique and rather useful for any person who needs to assemble a network of RTCM corrections or other data sources for their own purposes. One of the most notable of these is how data is gathered into the caster itself. SNIP supports five basic methods to gather the data which it then serves out to others: that of PUSH (In or Out), RELAY, and UART. A final method, called NEAR, allows creating a collection of the other type and then automatically sending the best data to each NTRIP Client.
- PUSH-In Data, the traditional NTRIP flow of data sent to it by a remote NTRIP Server device, used by large and small network operators. [PUSH-Out is simply sending this data on to another Caster]
- RELAY-REMOTE Data, which is NTRIP data gathered from another Caster, with SNIP connected as a Client to that Caster.
- UART Data, where a local serial or USB port is used to connect to a data sender (typically a GNSS reference station), and the need for an intermediate NTRIP Server (the poorly chosen name of the element that sends the data from the GNSS devices) is no longer needed.
- PUSH_Out Data, where your SNIP node is also acting as a NTRIP Server device to forward you data to others, while does all of the above as well. This is an output, not an input and is used to federate a mesh of cross connected data sources.
We show these four types of “streams” along with the connected NTRIP Client users in the below dialog which is used in the knowledge base documentation [the NEAR type is not shown].
The Remote-RELAY solution. Unlike a more traditional Caster, SNIP will reach out and connect to other remote Casters to create (we use the term federate) a custom network from these heterogeneous sources. This allows building up a network made up of the data streams you wish to use for consistent data logging and management. See the “Relay Streams” tab below for details.
The Serial UART solution. For many applications, the additional cost of having a GNSS reference station that implements the NTRIP Server protocol (and therefore sends data to a predefined Caster) is cost prohibitive. Such devices can often also connect and send data with a serial port (also referred to as a UART port or a USB). SNIP provides a ready means to connect one or more of such devices directly, overcoming the need for the NTRIP Server element.
These different types of data streams, along with the need to manage the clients and the status of the caster itself, has led to the tabbed display used in the SNIP GUI.
The Major GUI Tabs of SNIP
Each tab is discussed in turn below in its own article.
Each tab focuses on the management of a single aspect of operating the SNIP Caster.
Click on an image below for further details.