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: Florian Kiera
Subject: Re: [Question] gpsd, ntrip & C94-M8P (u-Blox)
Date: Thu, 14 May 2020 09:27:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

Hey Gary!

Am 13.05.20 um 18:34 schrieb Gary E. Miller:
Yo Florian!

On Wed, 13 May 2020 12:26:13 +0200
Florian Kiera <address@hidden> wrote:

      UBX-NAV-SVIN:
        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
Everything got wiped :/
Yup.  How did you do that?
I don't know how. :/ It gave out RTCM3 messages (gpspipe -w) until I used the ubxtool

Your USB is blocking RTCM3 out.  Are you getting RTCM3 from another
port??
Nope, all through USB.
Well then, that is your hard failure.
Usually ain't blocked.

How are you getting the RTCM3 out of the base into the rover?  The
base is blocking RTCM3 out on the USB port.
RTCM3 whereabouts: Before I used as mentioned in past emails the
RTKLib's str2str for Base->Caster and gpsd for Caster->Rover. No
RTCM3 probably causes 3D fix?
Yup.  RTCM3 is the data from the base that the rover uses to adjust
its observations to get an RTK fix.

What are you sending to with ubxtool that is not doing what you
think it should?
As described below, I just used "gpsd -n /dev/ttyACM0" to get a
running gpsd and than used the ubxtool command "ubxtool -p STATUS -p
CONFIG -P 20.30".
Yes, but what did you do before that to enable RTCM3 out from the base and
start the survey-in?
Used u-center to configure UBX-CFG-PRT and UBX-CFG-TM3 to RTCM3 out and survey-in. Types of RTCM3 messages that are needed were configured on UBX-CFG-MSG (1005, 1077, 1087, 1230)

RTCM3 messages have been turned off and protocol out has been
modified, as well as the dynModel
Yes, why/how did you do that?
Ubxtool -p STATUS -p CONFIG -P 20.30
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.
That's what I saw too and make me believe ubxtool changed it because
I haven't touched a single setting until than (and it was streaming
RTCM before). I don't really know how to use the ubxtool to change
the settings of the M8P's either.
Asked and answered.  Let us not go in circles.

All this appeared after using "ubxtool -p STATUS -p CONFIG -P 20.30"
No, that is when you discovered it.
I haven't changed anything... neither with u-center nor with the ubxtool itself (which I don't even know how to use properly to setup configurations). All I did was setting up gpsd to connect to the port and use ubxtool status/config output.

I've got 2 rover outputs (one where I started gpsd with "gpsd -n
/dev/ttyACM0 -G ntrip://usr:pw@192.168.1.1:2101/BASIS", the other
just with "gpsd -n /dev/ttyACM0")
Uh, two gpsd can not use the same tty at the same time.
Agreed. I stopped the old gpsd else it wouldn't work for sure.

since even parsing it with grep
ended up in a huge mess
I can't comment on messes you make without seeing how you did it.
Just ran "ubxtool -p STATUS -p CONFIG -P 20.30"... Since its hard to believe I will send just a quick summary of my console log. ALL I did was connecting my completely setup base M8P to my computer, ran "gpsd -n /dev/ttyACM0", used "gpspipe -w" to show it does send RTCM3 messages, ran "ubxtool -p STATUS -p CONFIG -P 20.30" and than "gpspipe -w" again. The outcome of the 2nd "gpspipe -w" shows TPV messages only, so indeed there must've changed something. (RTCM3 messages have been turned off, UBX and NMEA protocol output only) There is nothing else that effects the M8P at this point, may this makes it more clear what made me think that ubxtool messed it up. :/

Odd behavior of ubxtool aside:

My base sends RTCM3 messages and gpsd on the rover end is getting them and provides them to my M8P (rover side). How is it not changing to RTK Float/Fix but to DGPS? Was the 2nd output of "ubxtool -p STATUS -p CONFIG -P 20.30" any better than the first one to solve the DGPS/RTK miracle?

Regards Florian

Attachment: ubxtool_does_something.txt
Description: Text document


reply via email to

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