gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gary E. Miller
Subject: Re: [Question] gpsd, ntrip & C94-M8P (u-Blox)
Date: Tue, 28 Apr 2020 12:58:30 -0700

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.

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.

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

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.

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

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

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

You mis-parsed what I said.  I meant to be clear that gpsdecode could
use work.  Not that the input was incorrect.  Not that you did anything
incorrect.


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

Then purposely wrong.  RTFM.

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

> > I assume this is "-p STATUS"?  What happened to the ACk/NAKs??  
> I don't know

Was my assumption correct?  Or not?

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

Looks like a good catpure.

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

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

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

Attachment: pgpcn8e3faafx.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]