How to connect to the RTK2go software service.
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.
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: rtk2go.com:2101 (port 2101). [Hint: You can also point any common browser this page as well, SNIP will return the Caster Table as an HTML page when a non-NTRIP client connects.] If you software cannot resolve DNS names, point to: 220.127.116.11: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: The community password will be changed at the end of 2018
Note: If you have requested that your data stream use an reservation, then the private password for that reservation should be used.
To repeat, you do not need a user name to connect; either when getting data (NTRIP Client) or when sending data (NTRIP Server) to the Caster. If your software requires a name, enter anything you wish, the SNIP Caster will simply ignore it.
Note: For those connecting with NTRIP Rev2 protocol devices. SNIP accepts these connections, but Rev 1 is preferred. If your device requires a user name as well as the above password in Rev 2 mode, enter any text you prefer. SNIP will simply ignore it. Users with a Trimble BD992 Base Stations, this line is for you.
The name that you pick will be unique to you and your data stream. Please try to follow these simple rules:
This article can be helpful to understand how to read a mountPt in SNIP as well as many other NTRIP tools.
The most common connection problem seen on the RTK2go.com 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. The Caster gets over a half million such connections a month.
Either is fine. There are no limits on usage. Some data providers 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 your own copy of SNIP if needed.
We will periodically add reservations for data stream that are connect for longer periods of time. This allows us (and you) to collect usage data which is then used when you request the status of that data stream using the web interfaces. This is most often done on Monday mornings for stream that have been connected for several days and show that rover devices have connected to them.
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.
A quick way to see a map of current data sources is this link, then press the “View All” button at the bottom right side to see the table as a map.
A quick way to see if any data source was once present but is no long present is this link, scroll down to the “Former Data Streams” section.
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 (while the other mountPt was still connected). 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.
Reverse RTK:. 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, many inexpensive devices (such as the uBlox 8MT chip) can now also output in the RTCM3 format directly. [The 6T chips required RTKLIB or similar] 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.
DSRC Use: SCSC maintains other machines for those developing RTCM corrections over DSRC, please contact us for access and details. SCSC can translate and provide RSU and OBU ready data streams.
Datum Offsets: If the frame of reference for your source data needs to be adjusted (such as NAD to WGS), please contact us with the translation you will need. This can be accommodated with your reservation details. (more on this topic can be found our knowledge base). You can also perform this PFAT translation with your own copy of SNIP before sending the data to RTK2go.
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. This button is also available as a report in the document viewer. The Ban.. button allows managing the list of IPs which have been banned for a periods of time for abuse. ]