This article restates the details which are used to send your data stream to the public RTK2go Caster using SNIPs prior reservation system. Refer to the RTK2go Caster web page for current updates and details.

In this use case your GNSS device is a data sender acting as an NTRIP Server, sending corrections data to the SNIP NTRIP Caster which implements the RTK2go service.  We presume here that you (or your end users) also know how to set up and operate an NTRIP Client to get this data stream back out for your end users.

The Legal Stuff

Terms of Use: By sending your data to this Caster you affirm that a) you have the right to do so, and b) you consent to allow others to freely use your data, and c) the Caster owner / operator shall be held harmless for any faults or loss – real or perceived.   The Caster owner / operator (SCSC) reserves the right to remove or block any party for abuse.  [See this note]

All New RTK2go Base Station Providers:
Please Register before use

The Technical Stuff

SCSC staff can set up a reserved slot for a user upon request (there is no charge).  A reservation has the advantage of ensuring no one else will use the mountPt name you select and if the stream is “parsed” then the Caster Table Entry is automatically set for your stream based on the messages observed by SNIP in the data stream.

Unless you are sending CMR+ or a proprietary format, we recommend you have SNIP parse the data stream.  The RTK2go Caster is set to AUTO parse any new connections without reservations in order to support user with such stream types.   This means that both uBlox and various CMR data streams are examined, determined not to be RTCM 2.x or RTCM 3.x, and then not parsed further.

The normal method is for all reservations to result in “public” data streams, in that they appear in the Caster Table for others to see.  If you want your data stream to remain “private” to others, please tell us as part of the below. [Here is how to set this feature up on your own copy of SNIP]

You may send a request for a reservation to us by email at support [at] use-snip.com and these requests are typically processed within one day.  In your post please tell us the following:

1. What is the mountPt Name, with correct capitalization you want to use
2. If you want the stream to be Parsed
   (if you do not tell us, we will set the stream to be parsed)
3. If you want the resulting stream to be Public or Private   (to appear the Caster Table for others to see it)
4. What is the “City Name” you want to appear in the caster entry (if any)
   Often this is the human readable name of the of region such as “Glendora, California”
5. What private password string you want to use. Do not share this with others.
   (if you do not provide one we will assign it and tell you what to use).
6. If this data will come from a fixed IP, tell us what that will be and we will use it to prevent connections from any other IP.

We would also love to have a line or two about your use of this service, but that is not required.

Your users (the NTRIP Clients who will get this data) do not need a user account or a password to obtain this data, because the RTK2go Caster is run in an OPEN mode of operation similar to our other OPEN Caster.

Sending from SNIP, a PUSH-Out Stream

In SNIP the sender of the data is called a PUSH-Out stream.

Receiving the data in SNIP, a PUSH-In Stream

In SNIP the incoming data is called a PUSH-In stream.

The RTK2go Node Itself…

Is implemented with a stock copy of SNIP, running the Pro model.  You can operate your own copy with similar services by downloading a copy of SNIP directly.  The RTK2go project was created to support those deployments who do not have access to a static IP to publish their data streams.

But it did not work….

The only reason a data stream would be rejected by RTK2go is because of repeated continuous attempts to connect with incorrect passwords & credentials.  Most often this is either an with ill-formed protocol messages over a span of thousands of connections over many hours, one that simply never sends any data after connecting. RTKLIB software is known to connect with no data present, check to make sure you have actual data to send!

SNIP has built-in logic to detect and react to IP sources which persistently fail to connect to the Caster.  This copy of SNIP sets the IP Ban logic thresholds fairly high to avoid such problems with inexperienced users, but with persistence you can manage to get your IP banned for a period of time.  Most typically this occurs when some user has not set the connection values correctly but has also not bothered to look at the html replies sent by SNIP.  When an IP is in a banned state, it is simply disconnected without further processing.

Ban states can last from  minutes to days depending how the SNIP node has been set.  SNIP also provides for permanent bans of an IP in the Pro model and we have had to use that in some rare cases.

Because the ban affects the IP itself, you can often use a browser to see if your own node has been banned. If banned, you will see a message similar to the below while the ban lasts.  To protect the Caster, not further information is provided.

The NTRIP Caster has banned your IP:

The IP address XXX.XX.XX.XXX has been Banned from connecting to the Caster.
This IP has failed to connect over 30 times in a row without success. Once the ban period has lapsed you will be permitted to try and log on again.
During the ban period all IP requests (including obtaining a Caster Table) are denied. Please check your log-on details and the mountPt string you are sending. This event most often occurs due to incorrect user settings with sustained rapid retries. Please take a look at your NTRIP Client settings before contacting the operator.