How to Connect

How to connect to the RTK2go software service.

Top   SNIP Knowledge Base

Terms of Use:
By sending your data stream 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.

Connecting as a Data User…

When connecting to RTK2go as an NTRIP Client no log-on account is required.  We run this caster in an open mode.  Simply point your NTRIP client to:   (port 2101).   [Hint: You can also point any common browser this this pages as well, but the most recent release of Chrome now gets picky when it sees the the textual Caster Table returned rather than a web page and refuses to show it]

Connecting as a Data Provider…

When connecting to this site as an NTRIP Server (to send data to RTK2go) a connection password is needed. Point your server to:   (port 2101).

This password will vary over time to prevent abuse.
At this time the password is  BETATEST  (all caps).
Any well formed NTCIP connections are allowed.

Note: If you have requested that your data stream use an reservation, then the private password for that reservation should be used.


Picking Your Stream Name…

The name that you pick will be unique to you and your data stream. Please try to follow these simple rules:

  1. If there is a conflict (a dupe), the SNIP Caster will rename the stream to make it unique.  This may confuse your NTRIP Client users who expect the initial name. Consider getting a reservation setup.
  2. If there is a conflict from the characters used (such as a “;” in the name) the SNIP Caster will reject the connection.  This rarely occurs because most reputable software prevents entering such data.
  3. Use the ASCII characters a~z, A~Z and ,-_ to avoid issues.
  4. All mountPt names are a single string with not white space allowed.
    So “My MountPt” is not valid, but “MyMountPt” is valid.
  5. All mountPt names are always case sensitive.
    So “MyMountPt” and “myMountPT” as considered two different streams.
  6. Do not pick the mountPt name “SNIP” as this mountPt string is reserved for special remote command and control uses for Pro users and its abuse can lead to your IP being banned.
  7. If you rend users will enter your mountPt with gloves on (Precision Ag in the wintertime), consider using lower case letters and keeping it short.
  8. Please keep in mind you are not the only user with an Ag Leader, Emilid, EOS, Hemisphere, John Deere, Leica, RTKLIB, Septentrio, Spectra, Topcon, Trimble, uBlox, etc. etc. Base Station device, so it is best to avoid using that as the only name string.
  9. Similarity generic terms like “test” “baseStation” should be avoided to prevent conflicts.
  10. Please keep in mind also that just because you do to see a name conflict right now, another habitual user may connect their data stream when you normally sleep. Again, reservations can solve that.

This article can be helpful to understand how to read a mountPt as well.

The most common connection to the NTRIP Caster is from a “confused” device seeking data from a mountPt that either has never been there, or is no longer present at that moment. We now get nearly a million such connections a month.


Long term vs short term connections

Either is fine. There are no limits on usage.  Some data provider leave their streams up 24+7 at all times.  Other elect to send data only when they need to conduct a field campaign.  We do not collect archival data from these streams and place them on an FTP site.  You can easily do that yourself with you own copy of SNIP if needed.


What can be there…

The number or the diversity of streams which you (or your end users) NTRIP clients will see at any given time depends on who else is logged at that time and providing (non hidden) stream data.

The image below was taken on April 20th 2017 and shows a few of the European “emlid” or “Reach” users sending RTCM 3.x style data to the RTK2go Caster.  FYI, this is an image from SNIP‘s basic map display mode.


At any given time you will likely see RTCM correction streams from all over the world.  This is shared resource, but just inform your users what unique mountPt name is yours.  If your personal chosen mount point name is suddenly labeled xxx_02 it means you (or another party) have sent RTK2go the same name for a mount Point more that once.  SNIP will not  mind but it will confuse your end users who will be seeking for the original name: xxx.  Unless you are using very common terms like “test” for your mountPt you will probably never experience this. And please keep in mind that mount point names are case sensitive.  This article can be helpful.

Most published streams are in the RTCM3 format, but there is no restriction or limit on this.  The uBlox proprietary format is also popular for 6T and 8M devices (uBlox is a low cost L1 only device).  Often people use the RTKLIB‘s STRSVR (Stream Server) tool (written by Tomoji Tokasu) to translate these device feeds into RTCM 3.x before pushing them to RTK2go, or to their own copy of SNIP.

Avoid this issue by setting up a reservation for your data stream.

If you want to determine a rover device’s position with either SNIP or with a 3rd party app by reading the data you publish, then RTCM3 is the message set you will need to support.  Over the last few years or so, many inexpensive devices (such as the uBlox 8MT chip) can now also output in the RTCM3 format directly.   If your Android phone has the “Nougat” operating release or better, it too can send RTCM3 data to our Casters using some free 3rd party apps.


On Parsing

Right now we are running this Caster in SNIP‘s  intelligent “auto parsed” mode.  If RTCM 3.x data is found, the data will be parsed, no RTCM3 content will be filtered, and Caster Table Entry will be filled out for you.

If RTCM3.x data is not found, than whatever you send to it in PUSH-In mode is available to others. You (that is, your NTRIP Server software) needs to also fill out the Caster Table entry for your data in the normal way.  Sending CMR/CMR+ data will result in the data stream not being parsed, so all the data is then sent on the connected users.

Most network operators prefer to run their own copy of SNIP in with the default parsed mode enabled, so that any inbound RTCM3 streams will have the caster table entries automatically filled in and/or corrected for them.  And incidentally, most network operators do not you want you to send them your data stream unannounced.

[SNIP owner/operators: You can use the List Recent IPs… button (on the Clients Tab next to the List Current Users… button) to see a list of the IP addresses that have tried to connect to you.  The Ban.. button allows managing the list of IPs which have been banned for a periods of time for abuse.]