SNIP fully supports both NTRIP Rev1 and NTRIP Rev2 connection styles. SNIP also provides an auto-fallback for connecting NTRIP Clients that need to use one or the other format. From release 2_11_00 onward, SNIP allows you to select how it connects to other NTRIP Casters using either the Rev1 or Rev2 protocol styles. How to control this is discussed below after a quick review of the differences between Rev1 and Rev2 NTRIP formats.
For the most part issues with Rev2 connections come up when higher grade devices (Trimble, Topcon Leica, Hemisphere, etc.) need to connect to the SNIP Caster (they connect acting as NTRIP Servers). Many of these devices now default to using the Rev 2 protocol for connections. Many lower cost devices, including those based on RTKLIB source code, do not use the Rev2 protocol. The overall industry adoption of various Rev2 features remains very low. For SNIP this issue can come up when you create a PUSH-In reservation for such a device. You must then determine if it will connect using Rev1 or Rev2 and set the reservation details accordingly. Unlike the NTRIP Client connections which can safely drop back from Rev2 to Rev1 (auto-fallback), NTRIP Server connections compromise their connection security if this is done because the user name field is lost.
How do these two connection formats differ? Well the stock answer on this site is to suggest that you should buy a copy of the actual RTCM standard (from here). But a very terse summary follows. When the protocol was first developed the term “GET” was used in the normal HTML fashion to request a stream. The term “SOURCE” was used to send in a stream (NTRIP was influenced by a protocol called shoutcast). And strictly speaking, that is not a suitable HTML verb to be used, which the Gods of the internet made very clear to us all. So it was replaced with the more customary “POST” and the password was moved into the header data and encoded in Base64 along with a user name for greater security. A few other changes were also made. Here are two (simplified) example NTRIP connections to send in data to a Caster showing the differences.
NTRIP Rev1 example
SOURCE password /MyBase Source-Agent: NTRIP myTool/rev STR: Glendora, CA;RTCM 3.1;1004(1),1005(10),1012(1);2;GPS+GLO;SNIP;USA;34.13;-117.83;0;0;sNTRIP;none;N;N;0;; Accept: */* Connection: close
NTRIP Rev2 example
POST /MyBase HTTP/1.1 Host: ntrip.someDomain.net Ntrip-Version: Ntrip/2.0 Authorization: Basic dXNlck5hbWU6cGFzc3dvcmQ= User-Agent: NTRIP myTool/rev Ntrip-STR: ;Glendora, CA;RTCM 3.1;1004(1),1005(10),1012(1);2;GPS+GLO;SNIP;USA;34.13;-117.83;0;0;sNTRIP;none;N;N;2380;none; Accept: */* Cache-Control: no-store, no-cache, max-age=0 Connection: close
In the second example above the text “HTTP/1.1” is a historical typo which appeared in the published standard that has now become commonplace as some devices expect it. The Base64 decode of “dXNlck5hbWU6cGFzc3dvcmQ=” is “userName:password”
Using NTRIP Rev2 Connections in SNIP
You do not have to do anything to support both Rev1 and Rev2 connections, this is fully automatic. [Rev2 connection support is not provided in the Lite copy of SNIP. But as almost all devices support auto-fallback this is less of an issue.]
The Remote-Relay slot connections have your SNIP node connect to a remote NTRIP Caster by acting as an NTRIP Client to obtain the data. The SNIP side initiates the connection to the remote Caster or device. The default behavior is to connect using NTRIP Rev1. However by checking the box marked “Use NTRIP R2” you can instruct SNIP to use the Rev2 format when connecting. Note that an account with a suitable user name and password is still required at the other end.
In the SNIP vocabulary, PUSH-In slots are how remote Base Stations connect and send data to SNIP. These devices initiate the connection and act as NTRIP Servers, pushing their data to SNIP. In the Rev1 format, either a community password is used, or a password for the reservation created for that mountPt name. In Rev2 there is no similar concept to a community password, and every connection requires both a user name and a password which have been reserved for that mountPt name.
The default behavior for SNIP are to use a Rev1 format, but by checking the box marked “NTRIP Rev2” the reservation can be setup for a Rev2 connection. When this box is checked, the User text field is also enabled to allow entering a suitable log-on name. The selected name can be anything and need not relate to any user account names owned or assigned to the same party. Note that the password field is always enabled as this is required in both Rev1 and Rev2 formats. The connecting devices MUST use the format selected in the reservation. You will see various warnings and details in the console log if a connection attempt mangles any of these values.
Note: When Rev 2.11 or a new copy of SNIP is run on any older installation, all existing reservations are converted to the new format that supports both Rev1 and Rev2. But all of these connections are then set to be Rev1 (the most common). If you have any existing reservations that need to use the Rev2 format, you will need to edit these to be Rev2 and also to provide a user name for each.
In the SNIP vocabulary, PUSH-Out slots are how SNIP sends data from one of its own streams to a remote NTRIP Caster. In this connection method, SNIP initiate the connection and acts as an NTRIP Server, pushing the selected data stream to the remote device. The remote device may support Rev1 and/or Rev2, and the connection details need to be set up to meet those requirements.
The default behavior for SNIP is to use a Rev1 format, but by checking the box marked “Use NTRIP Rev2” the connection can be set up to use a Rev2 format. When this box is checked, the User text field is also enabled to allow entering a suitable log-on name. As with PUSH_In, the password field is always enabled as this is required in both Rev1 and Rev2 formats.
Support for NTRIP Rev2 connections is not provided in the free Lite model of SNIP. If you require this feature, please consider purchasing a copy of the Basic model of SNIP.
The SSL check box shown in the above images is a future item on the SNIP development roadmap. Today almost no NTRIP Clients support correct TSL/SSL use, but this feature has certain desired benefits for secure machine to machine connections.