NTRIP client can not get data

[p0mp0k0]

Ntrip browser can list the source table of the ntirp caster, but rtknavi or strsvr can not get the data when it connect to ntrip caster, I used another ntrip client and it work correct. I tracked the network packet between the client program and ntrip caster, 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.

[DavidKelleySCSC]

p0mp0k0:
This sounds like you have set the connection type in the RTKLIB
tools drop down to be "TCP Client" and not to be "NTRIP Client" 
- 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 reuses the http
GET keyword and invents the new "SOURCE" keyword (used to send data
in).

A well formed TRIP request from 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=

    ======================

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

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 grey (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, go back to NTRIP Client mode (set in the dialog before this),
then change it to be empty.  

Regards, DC Kelley

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.
  —
    You are receiving this because you are subscribed to this
    thread.
    Reply to this email directly or view
      it on GitHub

[p0mp0k0]

I'm sure I set the connection type as NTRIP client, because TCP Client can not set the MountPoint. So you can use wireshark to capture the network packet both rtklib tools and the ntirp client which I download from http://igs.bkg.bund.de, you can see the difference between rtklib tools and nrtip client when the program send the request packet's protocol.

[DavidKelleySCSC]

p0mp0k0:
Very odd, I am looked into this a bit more, but not clear the client
you used. 

When you said "...the ntirp client which I download from"  I presume
you meant this page
http://igs.bkg.bund.de/ntrip/download
These are several there, Which tool did you choose?
I can grab that tool and do a packet level comparison. 

The example which I sent you was just grabbed off a copy RTKNavi
ver.2.4.2 and one of our SNIP casters.

Sounds like you are going to be using STRSVR ver.2.4.2, so I
repeated this with that tool. 

I set it to grab a raw uBlox feed (because I working with that
today), 
to translate it to RTCM 3 1002 and 1005 messages,
And to then send it back to the same Caster as an NTRIP Server.
It all works fine. 
Here is a dump of the protocol exchanges.
The first of these (connection #15)  is STRSVR as an NTRIP Client
connecting to the NTRIP Caster
The 2nd (connection 16) is STRSVR as an NTRIP Sever connecting to
the NTRIP Caster
(we call that a PUSH stream)  

Client [#C15] appears to an NTRIP Client connecting with:
  Client
    sent: ======================
  GET
    /uBlox6T HTTP/1.0
  User-Agent:
    NTRIP RTKLIB/2.4.2
  Authorization:
    Basic dXNlcjpwYXNzd29yZA==

    ======================
  Mount Pt
    [ uBlox6T ] is a match -
    allow connection.
  Client #C15
    from 69.75.31.227:49510 connected to uBlox6T at 2016/03/17 11:22:15 AM
    (local)
  Client
    [#C16] appears to an NTRIP Server
    connecting with:
  Client
    sent: ======================
  SOURCE
    foobar TEST
  Source-Agent:
    NTRIP RTKLIB/2.4.2
  STR:
    STR: Fake caster table

    ======================
  New PUSH Stream   
      connected, at Thu 11:22:17 AM (Local)
        NTRIP Client [#C16] becomes an NTRIP Server PUSH stream [#P01, TEST] 
        Now awaiting data from [69.75.31.227
      : 49511] 
      Re-Opening
    log file:  TEST_160317.rtcm, is 119.57 KB 

And here is a copy of of an NTRIP Client request from the Lefebure
NTRIP Client tool (I kind of like that one)
The Lefebure tool connects twice, the first time to populate the
table for the user, the 2nd time to connect to what the user
selected. 
Take a close look at the two GET line to understand the differences.
Client [#C20] appears to an NTRIP Client connecting with:
  Client
    sent: ======================
  GET /
    HTTP/1.0
  User-Agent:
    NTRIP LefebureNTRIPClient/20121217
  Accept:
    */*
  Connection:
    close

    ======================
  No mount
    point requested, sending caster table and disconnecting.
  Client #C20 Disconnected
    (NO mountPt was
    provided), 98 Bytes in, 0 Bytes out, connected: 001 mSec
  Client
    [#C21] appears to an NTRIP
      Client connecting with:
  Client
    sent: ======================
  GET
    /uBlox6T HTTP/1.0
  User-Agent:
    NTRIP LefebureNTRIPClient/20121217
  Accept:
    */*
  Connection:
    close

    ======================
  Mount Pt
    [ uBlox6T ] is a match -
    allow connection.
  Client #C21
    from 69.75.31.227:49730 connected to uBlox6T at 2016/03/17 11:26:24 AM
    (local)

The above are log dumps from a Caster, easier to get then wire shark
or another protocol analysis tool,
but you can see the all important "GET /uBlox6T" part of the
request.  Without that part, no data will flow.  

Hope that so much text is helpful and not overwhelming. 
Please let me know which tool you downloaded, and I will get that
and build up a table for people to be able to compare with.  

Regards,   David Kelley 

On 3/17/2016 10:54 AM, p0mp0k0 wrote:

  I'm sure I set the connection type as NTRIP client, because TCP
    Client can not set the MountPoint. So you can use wireshark to
    capture the network packet both rtklib tools and the ntirp
    client which I download from http://igs.bkg.bund.de, you
    can see the difference between rtklib tools and nrtip client
    when the program send the request packet's protocol.
  —
    You are receiving this because you commented.
    Reply to this email directly or view
      it on GitHub

--

[p0mp0k0]

Thank for your support, the tool download link is http://igs.bkg.bund.de/root_ftp/NTRIP/software/ntripclient.exe. BTW, could you please give me a test ntrip caster to do the test, I only have one available ntrip caster, so I get the different results maybe.

[DavidKelleySCSC]

p0mp0k0: Well that is the command line tool that Dirk Stoecker developed about a decade ago (the readme says 2007, but that reflects the version 2 of NTRIP which is still not very widely used). And it remains a very good starting point for anyone. (And for whats its worth, Dirk's decoder source code is used by just about everyone in the industry as a starting point, RTKLIB included.)

A quick look at what it produces is just a perfect generic request, here is what I see running it at a Caster on my home PC tonight...

Client [#C02] appears to an NTRIP Client connecting with:

Client sent: ======================

GET /gisar30 HTTP/1.1

Host: 192.168.1.24

Ntrip-Version: Ntrip/2.0

User-Agent: NTRIP NtripClientPOSIX/1.49

Connection: close

Mount Pt [ gisar30 ] is a match - allow connection.

Client #C02 from 192.168.1.24:61272 connected to gisar30 at 2016/03/17 07:51:31 PM (local)

Client #C02 Disconnected from gisar30 , 131 Bytes in, 5.70 KB out, connected: 12.071 seconds

So, I still think that there is something in the RTKLIB tool setting you were using that is odd, it is certainly able to do this sort of thing.

could you please give me a test ntrip caster to do the test If you are asking for a Caster account which you can use on a caster, that is easy. But fill out the registration forms you find on public sites, most are in fact free, they just take a day or so to set up. [If you are asking for an actual Caster to download, that remains out of reach for another month or so. ]

Our firm maintains a free and open caster at ntrip.itsware.net:2101 and you are welcome to connect to that. Using the tool you have, try one of these command lines: ntripclient -s ntrip.itsware.net -m SCSC ntripclient -s ntrip.itsware.net -m BRUX0

The first is a site in LA, the 2nd is in Belgium, and that mountPt has a zero at the end. When your screen is full of junk and you are hear beeps, well that is RTCM decoded as ASCII. Tell me your location and perhaps I can add a suitable mount point you can "relay" into, if you need this.

Aside: I do not know how to prevent Github from messing up the line layout of these listings when posted. Is there some sort of keyword I should be using? And is there a way to edit it once it goes up to restore the readability? I also posted the original post and reply it here this morning [ http://support.use-snip.com/forums/topic/using-ntrip-clients-vs-using-tcp-clients/ ], where I can control the layout a bit more. But if that offends, will take it back down.

On 3/17/2016 7:15 PM, p0mp0k0 wrote:

Thank for your support, the tool download link is http://igs.bkg.bund.de/root_ftp/NTRIP/software/ntripclient.exe. BTW, could you please give me a test ntrip caster to do the test, I only have one available ntrip caster, so I get the different results maybe.

[p0mp0k0]

Thanks a lot. I found the difference of the two client and confirm the rtklib tools is OK, I set the wrong connection argument.

[kozuch]

I have a similar problem with rtknavi - I use euref-ip.asi.it ntrip caster - I got registered, have username and pwd, rtknavi is not showing any errors but I see no satellites in the "base" view... i use CPAR0 mountpoint (other points not working too). This is strange, because the green rectangle next to the "I" input conf button is flashing (the second green box is base station)... Any help welcome!

[DavidKelleySCSC]

Jan:
Perhaps you are decoding this RTCM3 stream as another type
  (RTCM2?), please check the drop down menu to confirm the right
  type.  As you have deduced, the green "LED" means data arrived,
  not that it was successfully decoded.  The set up does no default
  to RTCM3 decoding, and this has tripped me up many times.  Also,
  the monitor tool will let you  look at your stream and can often
  be used to detect what is really coming out if you try different
  decoder formats. 

Good luck, DC Kelley

On 5/21/2016 4:25 AM, Jan Kucera wrote:

  I have a similar problem with rtknavi - I use euref-ip.asi.it
    ntrip caster - I got registered, have username and pwd, rtknavi
    is not showing any errors but I see no satellites in the "base"
    view... i use CPAR0 mountpoint (other points not working too).
    This is strange, because the green rectangle next to the "I"
    input conf button is flashing (the second green box is base
    station)... Any help welcome!
  —
    You are receiving this because you commented.
    Reply to this email directly or view
      it on GitHub

-- 

Regards, David Kelley ITS Programs Manager, SubCarrier Systems Corp. (SCSC) 626-485-7528 (Cell) 626-513-7715 (Office) 888-950-8747 (Main)

[kozuch]

@DavidKelleySCSC Thanks for such a fast reply! :) Yes I think I have everything set up properly, using RTCM3 too... I tried wrong username and it correctly reported "login error" so the user account seems to be ok. The LED is flashing both dark and light green...

I tried the ntrip.itsware.net:2101 with SCSC or BRUX0 from above (there is no login/pwd for it, right?) but the result is all the same... Do I need to use some "startup commands" or "receiver option"?

I must say that I can run 2 GPS units over serial (u-blox NEO-M8T) and they work nicely as base+rover (getting a stable fix in the fields only though (no buildings around) - I try in urban area (my garden) but I rather get float that is why I want to try base from server).

In the monitor tool when I choose (2) Base station + RTCM3 it looks like this (with your server - itsware, the euref server looks the same):

Are the correction data there at all? It is an Italian server, which can mean a lot :) I applied for other two casters (BKG, ROB) but I have no login yet so I can not compare it.

The base station link: http://www.epncb.oma.be/_networkdata/siteinfo4onestation.php?station=CPAR00CZE

I use this real-time: ASI (broadcaster, registration) - RTCM 3.0 : 1004(1),1006(10),1008(10),1012(1),1013(10),1033(10)

Few more screens:

Can you tell me where to look in the monitor to check that the corrections are ok? I have no rover input setup currently.

[DavidKelleySCSC]

Jan:
> a fast reply.  Was just dumb luck, is Sat morning here where
  I live. 

The caster at ntrip.ITSware.net is run "open" so not
  user/password is needed and if one is sent it is just ignored.  
  When making connections to someone elses devices by way of a
  caster you never need any "start up" commands (they took care of
  that).  [Aside: But if it is a virtual site you have to send it a
  NEMA-183 message so it knows how to localize things.  Most site of
  that type will connect but then send no data, so RTKLIB will time
  out and reconnect.  Some sites of this type can take up to a
  minute or so before they send the first data, which causes other
  problems to get going.  That does not apply here.] 

Your experience with with the uBlox M8T and your screen shots
  indicates you know how to set all the common switches here, so
  lets dig a bit deeper.  [My normal advice to folks who want to
  simply watch RTKLIB work, connect to two base stations within
  ~20km and some orbital data and you should see rapid convergence
  to a fixed state/ This let you play with RTKLIB knobs before
  moving to your own river device.]  

The RTK Monitor stream image of the base station looks good. I see
GPS and GLO observations.  Here is a very simple cheat sheet about
RTCM messages  if you need one

(http://support.use-snip.com/knowledge-base/an-rctm-message-cheat-sheet/)

READ -->  The RTK Monitor stream image of the overall RTK status
reveals two problem issues.  Look at the summary of message you have
gotten.  Look at the three lines with "# of Input Data xxx" for
this.  You have good base station data, but you have no rover data
(as you said in you text), and also you have no orbital data ("Nav"
here).  One of these three guys MUST provide you orbital data, with
no ephemeris there is no solution.  Connect to any caster with  an
"RTCM3EPH" stream on the 3rd input to solve this, unless your rover
will provide it.

Your third image show the same things, filtered for the a base
station context.  These correction data look fine.    

Please enable tracing logging (try level three) and then look at
what the Error/Warning display in the monitor tells you. It will
likely say it can not solve a navigation filter with no rover data.

So what missing here is the rover connection and some
ephemerides.    What is the caster and the mountPt for the site
"CPAR00CZE - 11527M001"  - perhaps I or other can check it real
quick. 

> Can you tell me where to look in the monitor to check that the
corrections are ok?
Your 1st graphic showed the base station data, and that it decoded
indicates it is likely to be ok.
You need to repeat this for the missing rover and the orbital data
(the next two items in the list)

This will tell you they are not present, once they are you can then
see if they are "ok" with the obs data screen.  Subtle issue of "ok"
are beyond the realm of simple RTKLIB use. 

To sum up a long reply, lack of a rover connection and lack of any
ephemerides.  

DCKelley

On 5/21/2016 7:29 AM, Jan Kucera wrote:

- cut - 

-- 

Regards, David Kelley ITS Programs Manager, SubCarrier Systems Corp. (SCSC) 626-485-7528 (Cell) 626-513-7715 (Office) 888-950-8747 (Main)

[kozuch]

@DavidKelleySCSC Thanks again, it is late in my timezone so I wont try anything more today. The missing rover is "intention" - without it surely I wont get a FIX :) but I thought it should not mind when I try to get the base station signal first? I simply miss any satellites for base (the SATs on main screen of rtknavi are blank for base - nothing there). I just want to get base sats alone like I can get rover sats alone. I tried to have a rover connected, but the result was the same (did not try monitor with rover). It seems like some obvious thing I must be missing here... Will try your latest suggestions soon and report again.

[DavidKelleySCSC]

I just had a reason to look at this page today and noticed that the lines for the Caster connection are garbled now, and not sure how to edit these.
But to anyone reading this and making your own NTRIP Client, in the lines above "GET /uBlox6T HTTP/1.0" should be on one line and there is a single space (two two and not a tab and not a cr\lf) between GET and the /xxx where xxx is the mountPt (such as uBlox6T) you are requesting.