Re: [Question] gpsd, ntrip & C94-M8P (u-Blox)

[Gary E. Miller]

Yo Florian!

On Thu, 23 Apr 2020 10:11:56 +0200
Florian Kiera <address@hidden> wrote:

> >> command: "gpsd -n /dev/ttyACM0 -G ntrip://:@IP:PORT/STREAM" only
> >> puts the information, the ntrip caster is giving out and the M8P
> >> is giving out, into the PC itself but not to the M8P (the USB port
> >> since it is not addressed at that point?).  
> > Uh, missing a bunch of details.  Are you now talking about the rover
> > config?  
> 
> 
> Yes, I was talking about the rover since its the part I want to use
> gpsd for. Using that command didn't make the green RTK LED of the M8P
> flash (no correction data received) but i was able to see the data
> from the ntrip caster and the M8P (rover) in gpspipe -w.

There are many different RTCM2 messages.  The u-blox can be picky
about the ones it wants for a solution.  So check that the str2str
and ntrip are sending the same message types.

> Receiving the information from gpspipe -w and RTKlib's stream2stream 
> function giving me the data as well:

The SAME data?  Many ntrip clients send data to the ntrip server to
modify what is sent.  This is badly documented.  For example, the
"send GGA" option.  Some NTRIP serves need it, but I can not find
doc on it.

> ./str2str -in ./str2str -in ntrip://usr:pw@ip/BASE (output is the
> console) ./str2str -in ntrip://usr:pw@ip/BASE -out
> serial://ttyACM0:19200 (made the RTK LED flash))

Seeing the actual data would be better.

> That outputs made me believe that the fixed stations part works 
> (Base->(using ntrip server)->ntrip caster). That for I made a check
> on the base side for now and concentrated on the rover.

That is the proof of the pudding.

> >> What worked for me was using RTKlib's
> >> str2str that uses an input stream (ntrip caster) and gives it to
> >> the output stream (the USB port of the M8P).  
> > And you are not using the serial port?  The common configuration is
> > to have the base send data to the rover over a port on the roer that
> > gpsd is NOT using.  
> 
> Haven't tried this so far because I thought gpsd is able to send 
> (correction data) and receive (relative accurate data) over the same 
> port.

Yes, it can, but the port 2 method is easier, and has a high success
rate.

> At the moment I'm only using the micro USB port of the M8P to 
> connect to my USB port.
> I will try to use the serial port as well I guess. (Still would like
> to solve it through one port (IF possible))

Getting things to work the simpler way first removes many variables
that could be tripping you up.

A few basic questions.  Only some F8P support RTCM3.  What are your
firmware versions?  How is are your F9P configured?

new feature, today, in ubxtool:
        ubstool -p CONFIG

Run that, base and rover, send the output here, that will help me see
how your system is configured.  u-blox problems usually boil down
to configuration problems.


> > You realize that is one really long run-on sentence?  I'm unclear
> > how to parse that.  
> Sorry for that one. I just wanted to explain what I'd like to do with 
> gpsd on the rover side. Obviously not well, sorry. gpsd is able to 
> retrieve data from ntrip caster, right?

Some NTRIP casters, in some NTRIP modes.

> I want to retrieve my correction data from the ntrip caster and paste
> it to the M8P. Basically what the str2str function of RTKlib does.

And something else.  You are not the first with this issue where
str2str works, but using gpsd does not.

> Sadly I cannot retrieve the position data from the M8P afterwards,
> because I only used one port and it will be used by RTKlib so gpsd
> cannot use it.

Not a problem, depending on how you do it.

> About gpsd I wanna use it anyway to retrieve the
> position information from the Rover's M8P just with str2str together
> it wont work.

It can.

> So I read the gpsd manual which says:

No need to read the man page to the people that wrote it.

> That for I thought gpsd could solve both of my problems: receive the 
> data from the ntrip caster and share it with the M8P & retrieve the 
> relative accurate position from the M8P

Yes.  Many make it work fine.

> > You made no mention of how you configured your base and rover and
> > how you verified that config.  
> 
> I've been using the User Guide of the M8P's and the u-blox center to
> set them up:

gpsd does not run on Windows.  gpsd does not use u-center.  I don't use
u-center.  Use ubxtool if you want help here.

Send the output of; "ubxtool -p CONFIG"

>  ____ B______ change the port settings of USB to protocol out: RCTM3 and 
> protocol in: none

Wrong.  No input protocol means you can't talk to it!!!

>  ____ B______ start a survey-in (TimeMode 3) to get the current location
> (for testing just an accuracy of 10m) or just set a fixed (absolute)
> position -> fix mode will go to TIME  
>  ____ B______ enable RCTM3 messages: 1005, 1077, 1087 and 1230 (all on 1
> tick for USB)

1Hz is too fast.  You can overload the serial lines.

You may also need 4072,0

>  ____ R______ change the port settings of USB to protocol out: NMEA and 
> protocol in: RCTM3

Which breaks gpsd...

> > Other people have done what you are trying, but it requires
> > changing the configuration  on the rover after you start the rover
> > gpsd.  
> You mean the rover's M8P's configuration?

Yes, I said" "changing the configuration on the rover".  And just above
I mentioned some of the incorrect settings.


> If so what would the 
> configuration look like/need to be like? =-O

No idea.  As I keep saying, this has been a common issue.  No
definitive solutions yet.

> Is there nothing more I can do through/with gpsd at that point?

Much.  Start with "ubxtool -p CONFIG".

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpYhR4tfDKYt.pgp
Description: OpenPGP digital signature