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

[Gary E. Miller]

Yo Florian!

On Wed, 29 Apr 2020 12:37:48 +0200
Florian Kiera <address@hidden> wrote:

> >>> Looks like a fatal error to me.  Any logs/doc on what your ntrip
> >>> server is expecting?  
> >> My ntrip caster is expecting 2 different requests: first the source
> >> request (base output). That for it needs a decode password and the
> >> stream it is sending to (encoding_pw@ip:port/stream).  
> > gpsd can not do that.  gpsd can only handle one ntrip URL that is
> > a complete spec of what to get from the caster.  
> 
> The first request is on base side. It works with str2str to send data
> to the ntrip caster. (./str2str -in serial://ttyACM0 -out 
> ntrips://:1234@ip:2101/BASIS)

Yes, normal.

> I want to use gpsd to receive rtcm3 information from my ntrip caster, 

Yes, you have explained that.

> which "gpsd -G ntrip://usr:pw@ip:2101/BASIS" does.

No, it does not.  I have said no to that many times already.  What was
unclear about my prior explanations that this is incorrect?

> I was able to see
> the RTCM3 information in gpspipe -w or -r.

Yes, normal.

> Since it does not work
> anymore because gpsd got an issue with the successful message from
> the caster (200 OK, Standard respond from any ntrip caster that is
> going to open the stream),

Did it ever work?  How do you know that is the problem?

> I cannot reproduce it and post here as
> log.

That is a problem.

> So whatever happened to gpsd while I updated to the git lab
> 3.20.1~dev must've caused the issue I now got with receiving data
> from the caster.

If you believe that is the case, then just use git to bisect to the
failing commit.

> So after all it is supposed to be 1 ntrip URL that
> gpsd uses as source for correction data.

Lost me.  What "it" supposed to strip what?

> >> As ntrip server I can also just use str2str which sends the data in
> >> the following syntax: "./str2str -in serial://ttyACM0 -out
> >> ntrips://:encoding_pw@ip:port/stream" instead of the open source
> >> ntrip server which I cannot tell what it exactly does.  
> > If you cannot tell, them I am totally lost.
> > You did not parse my sentence as I intended.  gpsd forwards the
> > ntrip data to a receiver, you did not specify a receiver.  So no
> > place for the ntrip data to go.  
> The base, server and caster never had any issues and provides the
> rtcm3 messages as intended to the rover computer.

Yes, you have said that many times.

> The problem was
> that I use "gpsd -n /dev/ttyACM0 -G ntrip://usr:pw@ip:port/STREAM"
> (/dev/ttyACM0 is my receiver! always been!)

And yet, just above, you said otherwise.  So I'm confused.

> which wont send the rtcm3
> messages to ttyACM0. Instead it just gathered all information.
> (gpspipe -r gpspipe -w)

How do you know it is not sending RTCM3 messages to ttyACM0?

The logs should tell you that.

> >>> Did you intend your rover to be set to dynModel 0?  
> >> I did not, I dont even know what exactly dynModel is. :/  
> > Then you have a lot of reading to do:
> >
> >      https://www.u-blox.com/en/docs/UBX-13003221  
> 
> Thank you for the data sheet. Still don't understand why setting base
> to "stationary" is wrong? Or why setting the rover to "portable" is?

No, you are set to portable.  Stationary would be best.

0 == portable == your base
2 == stationary == my recommendation.

Not that it matters much to the big issue.


> >>> [ntrip_caster_output_str2str.txt  text/plain (2337 bytes)]
> >>>
> >>> The interesting part would be the output TO the ntrip caster.
> >>> Clearly str2str is sedning something to the ntrip server to make
> >>> it happy that gpsd is not sending.  
> >> Base output? Cause that is what base_gpsd.txt is giving. str2str
> >> and gpsd don't make a difference, at least in point of base
> >> output.  
> > Only in survey-in mode.  YOu are not in survey-in mode that I can
> > tell.  
> 
> Fixed Mode. Gave a fixed position for testing. I don't mind if they
> are not that accurate but still faster than survey-in.

Survey-in can take seconds.  YOu are not saving any time.

> > SURVEY-IN can take just a few seconds.  Do it right, or don't do
> > it.  
> 
> It doesn't matter if I set a fixed position or survey in. Either way
> I get the rtcm3 messages from the caster that gpsd wont provide to
> the rover M8P (/dev/ttyACM0).

It does matter, your RTCM3 is better when surveyed-in.

Not that it matters much to the big issue.


> >>> I assume this is "-p STATUS"?  What happened to the ACk/NAKs??  
> >> I don't know  
> > Was my assumption correct?  Or not?  
> 
> About the status yes it was. I have written an overview about which
> file contains what information in the email as I've messed up adding
> the attachments. Thought it still would be clear with the file names.

Best to include the command you used, with the output, in capture files.

> My bad. "I don't know" was referred to ACK/NAKs.

Yes, i got that.

> >> base_x_v_and_p.txt contains the corresponding output of "ubxtool -p
> >> STATUS/CONFIG -v 2 -P 20.30"  
> > I thought you said not surveyed?  Not so:
> >
> > UBX-NAV-SOL:
> >    iTOW 200935000 fTOW -211415 week 2103 gpsFix 5 flags xdd
> >    ECEF X 371799346 Y 75076193 Z 511063547 pAcc 1
> >    VECEF X 0 Y 0 Z 0 sAcc 1
> >    pDOP 9999 reserved1 2 numSV 10 reserved2 62265618
> >     gpsfix (Surveyed)
> >     flags (GPSfixOK WKNSET TOWSET)  
> Doesn't it say gpsfix? I cannot tell why it says gpsfix (Surveyed)

It says Surveyed beacuase it is survey-in mode!

> >> rover_x_v_and_p.txt contains the corresponding output of "ubxtool
> >> -p STATUS/CONFIG -v 2 -P 20.30"  
> > Other than the survey confusion, looks good.
> >
> > No idea why it is not working for you.  
> 
> Well 2 things don't work now:

Just two?  A surveyed-in rover breaks everything.

> "gpsd -n /dev/ttyACM0 -G ntrip://usr:pw@ip:port/STREAM -N":
> felix@felix ~/Desktop/gpsd $ gpsd -n -G ntrip://usr:pw@ip:2101/BASIS 
> /dev/ttyACM0 -N
> gpsd:ERROR: shmget(0x47505344, 24512, 0666) for SHM export failed: 
> Invalid argument
> gpsd:ERROR: Unknown reply ICY 200 OK\x0d\x0a from Ntrip service 
> ip:2101/BASIS
> gpsd:ERROR: can't extract Ntrip stream from usr:pw
> gpsd:ERROR: ntrip://usr:pw: device activation failed.
> gpsd:ERROR: ntrip://usr:pw: activation failed, freeing device

That conflicst with what you said above.  You said the streeam was good
and gpsd would not send to the receiver.  This is different, but what
you said in earlier emails, the NTRIP stream is failing, so nothing to
send to the receiver.


> Using "gpsd -n /dev/ttyACM0 -G ntrip://usr:pw@ip:port/STREAM" did not 
> send the correction data from the ntrip caster to the port listed in
> the command.

That is receiving ntrip data, not sending.  You keep confusing base and
rover.

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

pgpSF9Jwhs8YG.pgp
Description: OpenPGP digital signature