|
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!
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 that. 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):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.Nor I am even close to an expert in ubx to actually know for sure what the GET means in the SET/GET request.
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
ubxtool.txt
Description: Text document
gpsd.txt
Description: Text document
[Prev in Thread] | Current Thread | [Next in Thread] |