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

[Florian Kiera]

Hey Gary!

Am 28.04.20 um 00:17 schrieb Gary E. Miller:
> Yo Florian!
>
> [rover_ntrip_caster_output_gpsd.txt  text/plain (320 bytes)]
>
> The contents:
>
> user@rover ~/Desktop $ gpsd -n -G ntrip://usr:pw@ip:port/BASIS -N
> gpsd:ERROR: Unknown reply ICY 200 OK\x0d\x0a from Ntrip service ip:port/BASIS
> gpsd:ERROR: can't extract Ntrip stream from root:root
> gpsd:ERROR: ntrip://root:root: device activation failed.
> gpsd:ERROR: ntrip://root:root: activation failed, freeing device
>
> 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).
2nd it expects a poll request (rover input) for the stream 
(ntrip://usr:pw@ip:port/stream). You can secure your streams with a user 
and his corresponding password which can be set in the config files of 
the ntripcaster. ICY 200 OK is the respond of the ntrip caster that the 
validation was successful to enter this stream. The stream opened before 
without any issue, so I cannot tell why its a problem now.
If it was not of interest could you please tell me what information you 
expect from me about the ntrip caster?
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.


> Also, with no GNSS receiver, nothing useful can be done with the ntrip
> data even if it worked.

As far as I know/read the M8P's are GNSS receiver. 
(https://www.u-blox.com/en/product/neo-m8p-series 
https://www.u-blox.com/en/product/c94-m8p?lang=de#tab-further-information 
source of information)
May I did the wrong setup on that point as well?


> [rover_config.txt  text/plain (11182 bytes)]
>
> The "-v 2" options would have decoded the messages a bit more.
>
> The NAKs are because you did not set "-P 20.30", so the wrong configs
> were requested.  Thus missing stuff.

Okay will send them again. Hopefully entirely and correct.


> Did you intend your rover to be set to dynModel 0?

I did not, I dont even know what exactly dynModel 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. Its also 
the same as the output of the ntrip caster (no mutation on the ntrip 
caster). So transfering data from base to the caster and retrieving the 
information from the ntrip caster is working (content could be wrong due 
to my wrong configurations). I cannot tell if there are content errors 
but the transferring of the information seems to be 1:1. The ntrip 
caster wasn't the problem with gpsd (not in the past, now it gives the 
OK error as described above). Using gpsd and str2str give the same 
output (gpsd just cannot give it to the caster?)


> [base_gpsd.txt  text/plain (6854 bytes)]
>
> Looks normal.  As you can see, the gpsd decode is marginal...

I only used gpsdecode for the str2str function because else its a binary 
output?


> [base_config.txt  text/plain (5835 bytes)]
>
> dynModel 2 for a base station???

Don't know what dynModel exactly means, probably did not set it on purpose.


> 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)


> [rover_status.txt  text/plain (3918 bytes)]
>
> Ditto on the "-P 20.30".
>
> I assume this is "-p STATUS"?  What happened to the ACk/NAKs??
I don't know
> [base_status.txt  text/plain (3887 bytes)] `
>
> Ditto on the "-P 20.30".
>
> I assume this is "-p STATUS"?  What happened to the ACk/NAKs??
Yes x_status is the status of the corresponding station
I don't know (copied 1 to 1 from the console)

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"
rover_x_v_and_p.txt contains the corresponding output of "ubxtool -p 
STATUS/CONFIG -v 2 -P 20.30"

Regards, Florian

rover_status_v_and_p.txt
Description: Text document

rover_config_v_and_p.txt
Description: Text document

base_status_v_and_p.txt
Description: Text document

base_config_v_and_p.txt
Description: Text document