{"id":5310,"date":"2018-04-25T17:53:25","date_gmt":"2018-04-25T17:53:25","guid":{"rendered":"https:\/\/www.use-snip.com\/kb\/?post_type=ht_kb&p=5310"},"modified":"2019-12-23T16:24:20","modified_gmt":"2019-12-23T16:24:20","slug":"how-not-to-succeed","status":"publish","type":"ht_kb","link":"https:\/\/www.use-snip.com\/kb\/knowledge-base\/how-not-to-succeed\/","title":{"rendered":"How not to succeed, RTKLIB"},"content":{"rendered":"

This article is motivated by an increasing number of users, often with RTKLIB based tools<\/strong>, who are unable to connect their Base Station data to SNIP<\/span><\/strong>.\u00a0 And as a consequence, are unable to connect their Rover device(s) as well.<\/p>\n

A common ‘bad’ setup<\/h3>\n

Consider the following two log entries taken off the RTK2go.com<\/a> Caster.\u00a0 This shows two events that are endlessly repeating until the the automatic IPban<\/a> thresholds are reached (the user then resumes in ~15 minutes when the ban lapses).<\/p>\n

In the exchange shown below, we first have a connection from a popular client\u00a0 (LefebureNTRIPClient<\/a>) seeking to connect to a mountPt that simply is not present at that time.<\/p>\n

[C9389<\/span>]: New Client [#C9389] appears to an NTRIP Client connecting from 103.xx.xx.11:49432 with:
\n[C9389<\/span>]: An NTRIP Client sent: ====================== (148 chars)<\/p>\n

 GET \/ABCDEFG HTTP\/1.0\r\n User-Agent: NTRIP LefebureNTRIPClient\/20131124\r\n Accept: *\/*\r\n Connection: close\r\n Authorization: Basic ZWFxaxJxOxJxVxFxRxNx<\/pre>\n
=END=
\n[C9389<\/span>]: No matching mount point, requested: [ABCDEFG], sending Caster Table and disconnecting.
\n[C9389<\/span>]: Disconnected client ‘xxxxx #C9389’ from: 103.xx.xx.11:49432 at 09:57:38.001 AM (local)
\n[C9389<\/span>]: 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<\/p>\n
This is a normal disconnect event when an NTRIP Client<\/a> requests a mountPt that is not present.<\/p>\n
TIP:\u00a0<\/em><\/strong><\/span> You can use the SNIP::STATUS<\/strong> 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.\u00a0 Scroll to the bottom of the listing.\u00a0 This command is helpful for the NTRIP Client user to confirm the requested mountPt was there to begin with.\u00a0 For the RTK2go.com site, here is the link<\/a> for this<\/p>\n
\n
 <\/p>\n
The very next second, we have a connection from RTKLIB (acting as an NTRIP Server<\/a>) to PUSH-In<\/a> data to SNIP<\/strong><\/span>.\u00a0 The format is plain but correct (it provides no Caster Table entry\u00a0 – that is okay SNIP<\/strong><\/span> will fix it with auto-parse).\u00a0 Therefore the new data stream is accepted and added to the Caster Table for other parties to see and use.<\/p>\n
[C9390<\/span>]: Client [#C9390] appears to an NTRIP Server connecting from 103.xx.xx.11:49433
\n[C9390<\/span>]: A remote NTRIP Server (was a Client) sent us: ====================== (68 chars)<\/p>\n
 SOURCE BETATEST ABCDEFG\r\n Source-Agent: NTRIP RTKLIB\/2.4.2\r\n STR:<\/pre>\n
=END= (an inbound PUSH-In data connection attempt)
\n[ABCDEFG<\/span>]: New NTRIP PUSH-In Stream [#I1495, From: 103.xx.xx.11:49433]
\nestablished at Wed 09:57:39 AM (local)
\n[ABCDEFG<\/span>]: New PUSH-In Stream [#I1495 started from C9390] connected,
\nat Wed 09:57:39 AM (Local)
\n[ABCDEFG<\/span>]: NTRIP Client [#C9390] becomes an NTRIP Server PUSH-In stream [#I1495, ABCDEFG<\/span>]
\n[ABCDEFG<\/span>]: Now is awaiting first data from [103.xx.xx.11 : 49433]<\/p>\n
[ABCDEFG<\/span>]: NTRIP PUSH-In Server [#I1495, ABCDEFG] disconnecting from its slot,
\n68 Bytes in, 12 Bytes out, connected: 10.409 seconds
\n[ABCDEFG<\/span>]: PUSH-In Server stream ABCDEFG [#I1495] was Removed,
\ndeclared stale: xx:xx@103.xx.xx.11:49433\/ABCDEFG<\/p>\n
As a review of the above will show, the ABCDEFG<\/strong> data stream never provided any data once it was connected<\/span>.<\/p>\n
The 68 bytes in the initial connection were the request, the 12 bytes back were the 200 Ok<\/em> reply.\u00a0 Nothing occurred with this stream thereafter (in fact the Caster was dealing with other clients during this interval).<\/p>\n
After 10~12 seconds of this, SNIP<\/strong> <\/span>disconnects any data stream that has never sent any data.<\/p>\n
[Details<\/em>:\u00a0 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<\/em> during this time.\u00a0 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.]<\/p>\n
The remote device then retries and the process repeats.\u00a0 Independent of this, the NTRIP Client tries in vain to connect to a stream that, even when present, sends to no data.<\/p>\n
What went Wrong?<\/h3>\n
At the sender end, they have reached the SNIP<\/strong><\/span> Caster and correctly connected to it\u00a0 (IP, port, and password work).<\/p>\n
At the sender end (the RTKLIB tool, probably the STRSVR\u00a0 (stream server<\/em>) tool or RTKNAVI in the Log Streams<\/em> mode) no data was ever sent out.\u00a0 This could be due to several reasons but the two most common are:<\/p>\n