[Top][All Lists]

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

Re: gpsd + ubx

From: Gary E. Miller
Subject: Re: gpsd + ubx
Date: Wed, 20 May 2020 09:21:55 -0700

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.

> After starting gpsd it will recognize my selected serial device as 
> u-blox device which is fine. Than it sends some dialog to the M8P 
> requesting UBX-MON-VER (line 58-59 and 62-63) and sets the rate of 
> different messages (line 64-83) along with setting the UART
> output/input (line 60-61).


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

> If
> polling the UART's (01) was the target why not using 
> b5620600*_01_0001*(checksum) (p 211 of the document from u-blox)?

Dunno.  Could you decode that in plain computerese?

One problem is that gpsd does not know if ttyACM0 is the native
u-blox USB port, or a USB-Serial converter on one of the u-blox
UART ports.

> Running "ubxtool -p CONFIG -P 20.30" doesn't seem to be a poll
> request only either (ubxtool_call.txt: output of "gpsd -n
> /dev/ttyACM0 -N -D 5" while "ubxtool -p CONFIG -P 20.30" is running).

Lost me.  What I need is the -v 2 output of the ubxtool that you
are running.  ubxtool is designed to decode the hex so that
humans do not need to.

Annotate that to what you do not like.

> As is also does on starting gpsd, it asks for a SET/GET 
> b56206001400*03*000000d0080000802500002700010000000000c2d1 (03 is USB 
> port this time) (line 89-90).

No such thing as a SET/GET.  No such thing as asterisks in hex.  Can you
please decode that hex into compurtese? hint: -v 2 with ubxtool.

> Again wouldn't be b5620600*_03_0001*(checksum) the better choice 
> especially in the situation we just want to poll and not set?

Can you please decode that hex into computese?  hint: -v 2 with ubxtool.

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

> The documents explanation made me up to the thought that the wrong 
> message type might've been used *if* you want to poll only. (which I 
> think ubxtool -p CONFIG supposed to do)

Sadly u-blox uses the exact same message type for polling and for
setting.  But different Which are very different from the commands to
get and set which are 9-series only.

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

reply via email to

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