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

[Florian Kiera]

Hey Gary!

Am 28.04.20 um 21:58 schrieb Gary E. Miller:

> Yo Florian!
>
> On Tue, 28 Apr 2020 10:25:58 +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)

I want to use gpsd to receive rtcm3 information from my ntrip caster, which "gpsd -G ntrip://usr:pw@ip:2101/BASIS" does. I was able to see the RTCM3 information in gpspipe -w or -r. 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), I cannot reproduce it and post here as log. 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. So after all it is supposed to be 1 ntrip URL that gpsd uses as source for correction data.

> So far this has worked for everyone.
>
> If you need otherwise, then send doc and patches.
>
> > If it was not of interest
> >       
> It is of interest, but with no doc, and nothing to test against, nothing
> anyone else can do.
>
> > could you please tell me what
> > information you expect from me about the ntrip caster?
> >       
> Documentation on what it expects, and a patch to make it happen.
>
> > 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. The problem was
    that I use "gpsd -n /dev/ttyACM0 -G ntrip://usr:pw@ip:port/STREAM"
    (/dev/ttyACM0 is my receiver! always been!) which wont send the
    rtcm3 messages to ttyACM0. Instead it just gathered all information.
    (gpspipe -r    gpspipe -w)
> > > 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?

> > > [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.

> > > It is surveyed-in?  Data in "-p NAV-SVIN"  
> > >         
> > I gave it a fixed position for testing around because else it would
> > take a lot of time whenever I restart my base computer. So no its not 
> > surveyed-in for now. (should do so when it goes into proper work)
> >       
> 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).

> > > 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. My bad.
"I don't know" was referred to ACK/NAKs.

> > I will provide the proper status information with "-P 20.30" I hope.
> >
> > 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)
    but after all I set it to Fixed Mode with a fixed position which is
    "ECEF X 371799346 Y 75076193 Z 511063547 pAcc 1". Maybe that
    "(Surveyed)" just means its surveying in data to calculate with the
    fixed position?
> > 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:

"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
^C

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. (As the first issue didn't occurred I was able to check on gpspipe -w)

Regards, Florian