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
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 NOT parse any new connections without reservations in order to support user with such stream types.
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” (a featured added from SNIP release 1.10 onward), 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:
- What is the mountPt Name, with correct capitalization you want to use
- If you want the stream to be Parsed
(if you do not tell us, we will set the stream to be parsed)
- If you want the resulting stream to be Public or Private (to appear the Caster Table for others to see it)
- 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”
- 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).
- 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, or with ill-formed protocol messages over a span of thousands of connections over many hours. 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.