[Top][All Lists]

[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, 12 May 2020 11:07:55 -0700

Yo Florian!

On Tue, 12 May 2020 11:06:35 +0200
Florian Kiera <address@hidden> wrote:

> >>> I don't see the GGA thing that is blocking gpsd on a lot of
> >>> casters...  
> >> Sounds good?  
> > Not good.  The GGA thing is bad.  
> GGA is NMEA right? I only transmit rtcm messages what is it needed
> for on the caster?

I have no idea what it means.  All I know is that most of the new
casters say they "require GGA".  I don't know anyone that knows what
that means or how to work with those casters.

> >> The rover's green LED is flashing which the user guide is saying to
> >> mean the M8P is in RTK Float mode (status).  
> > No u-blox has any LED's.  So this must be related to the unspecfied
> > board your u-blox is on.
> >
> > No way for us to understand without seeing your board doc.  
> C94-M8P ( The User 
> Guide is descriping 2 LED's a blue one that flashes when its
> receiving GNSS/GPS data and a green LED which indicates whether the
> rover is in RTK float or RTK fix or even none of the named. If the
> green flashes its supposed to mean its in rtk float mode, without
> flashes (just a green light) its supposed to be in RTK fixed mode. As
> before the User Guidance just could be missing information at that
> point (may green flash also can indicate DGPS?)

OK.  Since I can't see your LED's, the output of "-p CONFIG -p STATUS"
will have to suffice.

> >> I am using gpsd to receive all informations from the rover and
> >> check the gps_data_t => status (github: gps_fix_t.status).  
> > No one receives all the informamtion.  
> All necessary informations at the very least.

Whatever that is...

> >          ubxtool -p STATUS -p CONFIG -P XX

And I should have added "-v 2", but I can decode by hand.

> base_conf.txt->output of the ubxtool on my base

For some reason it is NAKing some things:

      NAK to Class x06 (CFG) ID x3b (PM2)

      NAK to Class x06 (CFG) ID x86 (PMS)

You have a time-only fix, but you are not surveyed-in:

      version 0 reserved1[0 0 0] iTOW 204030000 dur 0
      meanX 0 meanY 0 meanZ 0
      meanXHP 0 meanYHP 0 meanZHP 0 reserved2 0 meanAcc 0
      obs 0 valid 0 active 0

Your USB is blocking RTCM3 out.  Are you getting RTCM3 from another port??

     PortID 3 (USB) reserved1 0 txReady 0x0
      reserved2 [2256 9600]
      inProtoMask 0x23 outProtoMask 0x1
      reserved3 0 reserved4 0
        inProtoMask (UBX NMEA RTCM3)
        outProtoMask (UBX)

Do you intend to be moving base?

> rover_conf.txt->output of the ubxtool on my rover

Looks good, except that it is 3D fix, not RTK fixed fix.

How are you getting the RTCM3 out of the base into the rover?  The
base is blocking RTCM3 out on the USB port.

> Also ubxtool keeps resetting all my configurations anyways.

No.  ubxtool does nothing that you do not explicitly tell it to do.
All data it sends to the receiver is displayed for you to double check.

gpsd without the "-b" will change things silently, but not ubxtool.

What are you sending to with ubxtool that is not doing what you think it

> >> You've got other
> >> ideas that could improve it?  
> > As in previous emails.  Awaiting confirmation you fixed things as
> > previously recommended.  
> The only things you suggested me in view of the M8P's so far was
> editing the dynModel (which was right all the time, might've mixed up
> rover and base conf text files?) and using survey-in for the base,
> which I applied before checking the gps_data_t.status.

Swapping the files would explain what I saw.  But I do not see survey-in
in this set of files.  And no RTCM3 out on USB is also a big problem.

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: pgpeiF_bl2cCn.pgp
Description: OpenPGP digital signature

reply via email to

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