This article is motivated by an increasing number of users, often with RTKLIB based tools, who are unable to connect their Base Station data to SNIP. And as a consequence, are unable to connect their Rover device(s) as well.
A common ‘bad’ setup
Consider the following two log entries taken off the RTK2go.com Caster. This shows two events that are endlessly repeating until the the automatic IPban thresholds are reached (the user then resumes in ~15 minutes when the ban lapses).
In the exchange shown below, we first have a connection from a popular client (LefebureNTRIPClient) seeking to connect to a mountPt that simply is not present at that time.
[C9389]: New Client [#C9389] appears to an NTRIP Client connecting from 103.xx.xx.11:49432 with:
[C9389]: An NTRIP Client sent: ====================== (148 chars)
GET /ABCDEFG HTTP/1.0 User-Agent: NTRIP LefebureNTRIPClient/20131124 Accept: */* Connection: close Authorization: Basic ZWFxaxJxOxJxVxFxRxNx
=END=
[C9389]: No matching mount point, requested: [ABCDEFG], sending Caster Table and disconnecting.
[C9389]: Disconnected client ‘xxxxx #C9389’ from: 103.xx.xx.11:49432 at 09:57:38.001 AM (local)
[C9389]: Client ‘xxxxx’ #C9389 [103.xx.xx.11:49432] Disconnect (tried to mount ABCDEFG, not in table), 148 Bytes in, 8.12 KB out, Connected: 012 mSec
This is a normal disconnect event when an NTRIP Client requests a mountPt that is not present.
TIP: You can use the SNIP::STATUS command (if it is enabled on that node) to see a list of all the mountPts that were once present on the stream but are no longer present. Scroll to the bottom of the listing. This command is helpful for the NTRIP Client user to confirm the requested mountPt was there to begin with. For the RTK2go.com site, here is the link for this
The very next second, we have a connection from RTKLIB (acting as an NTRIP Server) to PUSH-In data to SNIP. The format is plain but correct (it provides no Caster Table entry – that is okay SNIP will fix it with auto-parse). Therefore the new data stream is accepted and added to the Caster Table for other parties to see and use.
[C9390]: Client [#C9390] appears to an NTRIP Server connecting from 103.xx.xx.11:49433
[C9390]: A remote NTRIP Server (was a Client) sent us: ====================== (68 chars)
SOURCE BETATEST ABCDEFG Source-Agent: NTRIP RTKLIB/2.4.2 STR:
=END= (an inbound PUSH-In data connection attempt)
[ABCDEFG]: New NTRIP PUSH-In Stream [#I1495, From: 103.xx.xx.11:49433]
established at Wed 09:57:39 AM (local)
[ABCDEFG]: New PUSH-In Stream [#I1495 started from C9390] connected,
at Wed 09:57:39 AM (Local)
[ABCDEFG]: NTRIP Client [#C9390] becomes an NTRIP Server PUSH-In stream [#I1495, ABCDEFG]
[ABCDEFG]: Now is awaiting first data from [103.xx.xx.11 : 49433]
[ABCDEFG]: NTRIP PUSH-In Server [#I1495, ABCDEFG] disconnecting from its slot,
68 Bytes in, 12 Bytes out, connected: 10.409 seconds
[ABCDEFG]: PUSH-In Server stream ABCDEFG [#I1495] was Removed,
declared stale: xx:xx@103.xx.xx.11:49433/ABCDEFG
As a review of the above will show, the ABCDEFG data stream never provided any data once it was connected.
The 68 bytes in the initial connection were the request, the 12 bytes back were the 200 Ok reply. Nothing occurred with this stream thereafter (in fact the Caster was dealing with other clients during this interval).
After 10~12 seconds of this, SNIP disconnects any data stream that has never sent any data.
[Details: If the data stream has sent data in the past, a longer time out period of 90 seconds is used. Additional logic is also used if the same stream tries to reconnect during this time. It can be common for cellular links to experience connectivity problems, but here we are concerned with RTKLIB connecting where there is no data available to be sent.]
The remote device then retries and the process repeats. Independent of this, the NTRIP Client tries in vain to connect to a stream that, even when present, sends to no data.
What went Wrong?
At the sender end, they have reached the SNIP Caster and correctly connected to it (IP, port, and password work).
At the sender end (the RTKLIB tool, probably the STRSVR (stream server) tool or RTKNAVI in the Log Streams mode) no data was ever sent out. This could be due to several reasons but the two most common are:
- The source data stream is not providing any data
- The “conversion” setting in STRSVR do not result in any messages to send
Correct this and it will work fine.
Or at least you will send your data to the SNIP Caster and then on to others.
What went Wrong, part II
The next step that folks often forget is that every Base Station MUST tell others the where it is at (it’s precise ECEF location once determined, but in this tool it is entered as LLH values). In the absence of this information, you will see messages coming to the rover device, but no fix/float process will start. In the RTKLIB STRSVR tool this data is entered in the Options… button at the bottom of the window.
The Options dialog looks like the below. This example uses a popular modification of the RTKLIB tools available from RTK Explorer which you can download from here.
Note the section marked in red where the ECEF values are enter as LLH. Aside, when sent in RTCM3 message (either MT1005 or MT1006) the raw data is sent as ECEF.
If you are getting data but are unable to “use it” confirm you are getting a MT1005 or MT1006 with the grossly correct Base Station location. If you have your own copy of SNIP (which after all is preferred) you can use several different tools in SNIP to see the RTCM3 messages and their internal contents. If it is working, but the position is “off” in some way, it is likely your precise position differ between what is sent and whatever is defined as “truth” are using different frame of reference (the datum and its realization).
Here is the above nonsensical position being displayed in the SNIP tooltip for the stream
Current copies of SNIP will also alert the operator when a stream sends in ECEF/LLH values that make no sense, such all zeros or the two poles. [You can in fact use the PFAT translations feature to move a base to thousands of km from its real location, but this would typically only be used for tests and is an rather advanced topic.]
Understanding and resolving this issue at the Base Station side overcomes the most common problem(s) that RTKLIB users have with any NTRIP Caster.