Using NTRIP Clients vs using TCP Clients

Data Users often get confused on the subtle differences between various connection types.  In the thread below a user is connecting to a Caster with a TCP connection in one case and with the NTRIP protocol in another.    The only reason to use TCP for such a thing is that you only need to send ONE data stream to the people who can connect [hence there is no need for a mountPt to be sent].  If you need more than one stream, of course the stock answer on this site is to use-snip for this.  The free Lite mode of SNIP is an excellent way to add an NTRIP Caster to your RTKLIB and Strsvr setup.

HintSNIP provide a special tab to manage data streams for users who may to use a RAW TCP/IP Connection to send data into SNIP (often from an older GNSS devices that does not speak NTRIP).

Shamelessly taken from the posts at the RTKLIB pages on GitHub
See Topic: [RTKLIB] NTRIP client can not get data (#144)

On 3/16/2016 11:51 PM, p0mp0k0 wrote:

Ntrip browser can list the source table of the ntirp server, but rtknavi or strsvr can not get the data when it connect to ntrip server, I used another ntrip client and it work correct. I tracked the network packet between the client program and ntrip server, I found rtklib’s tools request the data using TCP protocol, but another ntrip client using HTTP protocol, I think maybe this cause the issue.
BTW, both rtknavi and strsvr can not set the string that send to ntrip server when connect, the editbox is lock.


p0mp0k0:
This sounds like you have set the connection type in the RTKLIB tools dropdown to be “TCP Client” and not to be “NTRIP Client”   This is easily fixed but you have to be sure and do it in each tool for each connection.

These modes both use TCP/IP, HTML lives on top of that, and the NTRIP protocol is a very simple layer on top of that which reuses the http GET keyword and invents the new “SOURCE” keyword (used to send data in).

A well formed TRIP request from the RTKLIB tools looks like this, (plus the HTML customary final blank line)

Client sent: ======================
GET /uBlox6T HTTP/1.0
User-Agent: NTRIP RTKLIB/2.4.2
Authorization: Basic VXNlcjpmb29iYXI=
======================

Here you can see that the client has requested the mountPt “uBlox6T” (the word after GET /) and that they are using RTKLIB/2.4.2 as the agent.  The user ID and the password are also provided, using a simple Base64 encoding method. Other metadata may also be present, with individual lines appearing in various orders.

Hint: In SNIP, to see this data for each client connection as it occurs, enable the “Display New User Connection Details” check box found in the “Caster and Clients” Tab.  As new connections occur you will see data similar to the above in the console log. This is often very useful as a diagnosis aid when one of your clients is having connection issues.  A successful connection will also display the results in the console, like those below.

Mount Pt [ uBlox6T ] is a match – allow connection.
Client #CXXX from XX.XX.XX.XX:XXXX connected to uBlox6T at 2016/03/17 10:58:12 AM (local)

An unsuccessful connection attempt results in sending the current Caster table and then a disconnect, as per the NTRIP protocol.

Back to the original Github thread …

By contrast the same connection with TCP alone sends nothing, it just connects and waits for returned data.  This operational mode is of value when your source only has one stream for others to connect to, but not to a Caster which tends to have many streams.

Also: The GUI in the RTKLIB tool suite is a bit weird here (at least to me). When in this mode, the GUI for the mountPt text editor (and user and password) is disabled and gray (you called it locked) to indicate that it will not be sent. But you can still see it, which is confusing and frustrating (IMHO).  If you want the label to be blank, you must first go back to NTRIP Client mode (which is set in the dialog before this), then change it to be empty, then go back to the TCP Client mode and edit to it be blank.

Regards, DC Kelley

Follow this further at the RTKLIB pages on GitHub

Was this article helpful?

Related Articles