[Top][All Lists]

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

Re: gpsd + ubx

From: Florian Kiera
Subject: Re: gpsd + ubx
Date: Mon, 25 May 2020 16:21:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1

Hey Gary!

Am 20.05.20 um 18:21 schrieb Gary E. Miller:
Yo Florian!

On Wed, 20 May 2020 17:33:18 +0200
Florian Kiera <address@hidden> wrote:

I've been debugging gpsd input/output since I ran into some miracles 
regarding gpsd and my M8P's. The command I used for this was "gpsd -n 
/dev/ttyACM0 -N -D 5".
Good start.

Why does gpsd set the UART input/output protocol on start up?
Because gpsd tries to configure the device into a minimal working
state.  Don't worry so much about why.  Someone once, was in a hurry,
tried a bunch of things until something seemed to work, then
changed the initialization.

There has long been talk, but no action, to add a gpsd flag to skip

This wy you start gpsd, and THEN configure your recceiver.  As I
keep telling you, configuring your receeiver before starting gpsd is
the wrong way around.

Now this explains a lot!

How can I run "ubxtool -v 2" on an output of "gpsd -n /dev/ttyACM0 -D 5 -N"? Using a log file and try to read it with "ubxtool -r" sadly didn't work.

I am not 100% certain if those UBX-CFG-PRT request just have a poll 
purpose or actually supposed to change the protocol input/output to
for example UBX only out, all (UBX+NMEA+RTCM3) in.
Not supposed to change anything.

Easy to check.  No need to decode hex, just run ubxtool with -v 2 and
grab the output.  Or look in ubxtool at get_config(self):
Nor I am even close to an expert in ubx to actually know for sure
what the GET means in the SET/GET request.
I don't know what you mean by a SET/GET request. The term is not in any u-blox doc I can find. And note those are unrelated to the polling commands. The set command and the get commands are only in 9-series. They are different than the poll commands that are in all u-blox series.
About SET/GET: Check page 211 of

Had a look on get_config(self) and the ubxtool itself to find out that  "gpsd -n /dev/ttyACM0 -N -D 5" gives out different hex's to the ttyACM0 than ubxtool says.
I debugged ubxtool by adding the -V 4 and adding another line to only inspect the data (content) of the hex.
Thinking about it: May gpsd prepares the u-blox device to work with ubxtool whenever I execute "ubxtool" (like it does on starting gpsd)?

line 6076 in ubxtool added: sys.stdout.write("\nhex test1: " + gps.polystr(binascii.hexlify(msg[:m_len+4]))+ "\n")
gpsd.txt (running "gpsd -n /dev/ttyACM0 -D 5 -N")
ubxtool.txt (executing "ubxtool -p CONFIG -v 4 | grep "hex test")

At least all this would explain what messed up all the settings that I made before gpsd... down to use ubxtool for setting up base/rover now after running "ubxtool -p RESET" (export UBXOPTS="-P 20.30 -v 2").
How can I allow RTCM3 messages properly for my base (so it only sends RTCM3 messages (1005, 1077, 1087, 1230)? For binary(ubx)/nmea there is a shortcut, how can I change it to RTCM out only and use TMODE3?

Regards Florian

Attachment: ubxtool.txt
Description: Text document

Attachment: gpsd.txt
Description: Text document

reply via email to

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