As a general rule, SNIP can federate data from other Casters (including other SNIP installations) in any way you could care to connect such things. Use this ability to create the network you need, gather the set of data you need and to ensure that key data streams are distributed to others. Subject the license limit your copy of SNIP has for streams, there are no limits.
You can think of each copy of SNIP as something like a single Lego building block. It is up to you what will connect to what. A few common variations of this are further described in this article.
Single GNSS User
The typical “single node” use of SNIP involves connecting a GNSS source (often from a local serial port) to SNIP and letting others (NTRIP Clients) then connect to SNIP to share the data stream. Any party that can reach the SNIP node can connect to it (if allowed). This is perhaps the simplest use case. Variations of this involve connecting to other streams run by others (relay-remote streams) or having other devices send your SNIP node data (PUSH-In streams).
Many users who are new to using NTRIP start with such a configuration and then add additional data streams such as broadcasting improved orbital data or clock data, as their need grow. The low cost base station deployment referred to as “L1 only” or “uBlox + RTKLIB = base station” are also well served by SNIP in its Lite form.
Variations of the above basic approach include a great many configurations where the local GNSS device must by connected by intermediate cables, adapter boxes, Bluetooth, and other means to create a basic serial port. The rational for the use of these is often due to cost (many GNSS device makers charge an additional fee for the ability to send NTRIP Server data directly to a Caster).
Single GNSS User, no static IP available
The above use case works well if all your users can access the SNIP node. This typically means that they all exist on the same sub-net, or that the SNIP node has a static IP on the internet that other parties can reach. Variations of this also include using a commercial Dynamic DNS service (DDNS) to tell others where they can reach the SNIP node. These are all variations of network connectivity issues which must be overcome to allow others to reach your SNIP Caster.
However, in the absence of one of these solutions, SNIP can be used to easily forward the data streams it has (one or more) to another NTCIP Caster (provided by another copy of SNIP or any other standards conformant Caster). This 2nd caster is then used as the public location where the NTRIP Clients can connect. This is most useful when firewalls are involved or when no static IP is available.
In this image the SNIP Caster on the left is using a PUSH-out mode stream to cross the firewall and/or overcome the dynamic IP to reach the SNIP Caster on the right. The SNIP Caster on the right is accepting this data as a simple PUSH-In data stream. The SNIP Caster on the right can then provide this data (along with any other streams it has) to the NTRIP Clients.
Note that the sending caster must also know the correct log-in credentials provided by the receiving caster. [Technically speaking, in this case the sending caster is connecting to the receiving caster as an NTRIP Server.]
A final variation on this is to have the SNIP NTRIP Caster on the left connect using a relay-remote stream to the receiving caster and recover its own stream which is can then monitor for end to end quality assurance. This creates a “back haul” link to the original data source. This allows detecting issues such as message latency and drops out along the complete distribution route. [Technically speaking, in this case the final remote-relay connection to the right side NTRIP Caster as as an NTRIP Client device.]
Hint: If you need a public IP to send your corrections stream out to, consider using the RTK2go.com system.
Federating Data Streams
The easy ability to make these connections lends itself to creating ad hoc networks of data. Within reason such networks are to be encouraged. Here is an example where three SNIP Casters have been used to pass the data originally provided by the GNSS device shown on the bottom to each local user community. Note that each new layer adds (or drops) whatever content is needed.
Keep in mind that users often do this without you (the Caster operator) being aware of it. Please keep in mind you may need to first obtain data rights to do this with private sector data streams. Many of the mountPt streams found on larger sites such as rtgpsout.unavco.org or rtcm-ntrip.org are also rebroadcast over different networks with slightly different names. The mountPt AZ01_RTCM3 found on our open Caster site at ntrip.use-snip.com (on port 2101) is a good example of this. This stream, which is located in the city of AZUSA, is a simple GPS only station located at one of our local high schools, yet it is rebroadcast in multiple international networks.
A common problem to keep in mind when federating data streams from multiple other network is that they may be using different datums for the ECEF data they send.
Simple Data Logging
Many users record corrections data from SNIP for possible longer term use. SNIP has several simple FTP abilities to gather, compress, and save files in support of this. And of course raw data from any stream can be logged for long term storage. So field servery team use a copy of SNIP operating at the office to gather duplicate corrections data from what will be needed in the field. This is a simple way to ensure an uninterrupted data stream for post processing use or as a recovery mechanism should field losses occur. In this use case SNIP is being used simply as digital tape recorder.
A variation on this is to take one copy of SNIP out to the field site, connect it to a stationary cellular link back to the desired corrections source (using a remote-rely stream connection), and then distribute this stream using local RF and WiFi / WiMax to all the local survey teams members during the campaign. This can be considerably cheaper then using dedicated radio links.
Self Connections
It is also possible to send data from a SNIP node back to itself. This has little practical value other then consuming your machine’s MIPS and bandwidth, but is not prevented by the SNIP control logic. The normal logic found in SNIP to prevent duplicate mountPt names will be used when needed to ensure that every mountPt is unique (adding terms like “_02”, “_03” the the mountPt name as needed).