[Top][All Lists]

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

Fwd: Fwd: Re: gpsd + ubx

From: Florian Kiera
Subject: Fwd: Fwd: Re: gpsd + ubx
Date: Tue, 2 Jun 2020 10:30:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1

This mail was supposed to be send on the 28th of May, somehow it was not send properly. Maybe due to the size of the attachments... Hope decoding logs.tar.gz is fine

The issues I had with gpsd might be solved with the changes to driver_ubx.c!

Hey Gary!

Am 27.05.20 um 21:00 schrieb Gary E. Miller:
Yo Florian!

On Wed, 27 May 2020 13:58:18 +0200
Florian Kiera <> wrote:

I'd like to see you log of that.
ubxtool_call.txt: gpsd output when ubxtool is called (gpsd -n
/dev/ttyACM0 -N -D 5)
ubx.txt is the cut out of ubxtool_call.txt line 90 and exspecially
this message does something, I'd say gpsd shouldn't do. It changes
the output to UBX only.
Yes, line 90 is normal and as expected. I pointed you earlier
to the driver_ubx.c code that does that: ubxmode() called from

cat ubx.txt (originally no spaces)
b56206001400 03 00 00 00 d0 08 00 00 80 25 00 00 27 00 01 00 00 00 00
00 c2d1
That file, untouched, would have been useful.

ubxtool -r -f ubx.txt quits without any response sadly...
Missing message delimiters, also you forgot "-v 2" or better "-v 3".

decoding it by hand:
Yes, nothing new there. That matches the code.

Also quiet interesting that gpsd says the hex string is 14 bytes long
while its 20 long (20 is also right following the ubx doc)
Both are right, depending on framing, lengh, checksum, etc.
You can use the new -p option to gpsd to have it not autoconfigure
your device.
Updated to latest gitlab (gpsd-p.txt line 265-266): --passive doesn't
seem to work. Still sends hex messages to the ubx-device (gpsd-p.txt
line 136-166) executed "gpsd -n /dev/ttyACM0 --passive -N -D 5".
"passive" does not meman "readonly". It still sends messages.
The untouched file (where I extracted the hex messages from is ubxtool_call.txt). If you say its normal and fine than I will stop poking around in those sent messages. It either way works fine to me as the state is now.

Executing "gpsd -n -p /dev/ttyACM0 -N -D 5" doesn't work: option p
unknown. (gpsd-p.txt line 198-264)
Good catch, I did not add it to getopt(). Fixed in git head.

I warned people this is new code.

Latest git head doesn't work for me. Whenever I run "gpsd -n /dev/ttyACM0 -N -D 5" (the USB definition is needed to make gpsd not working) the gpsd starts things up and after getting a message from the ubx device (always the same) gpsd freezes and cannot be stopped except through "sudo kill -9 id".

Log of this: gpsd_crash.txt: will run it with D 10 there, gpspipe and gpsmon will be empty too         attachment

Maybe one of the driver*.c that were changed causes the loop? I tried to debug it with gdb, but was not able to generate any output. May need to spend some more time with gdb...

I downgraded to the version from 27th may to get the outputs below.

Without seeing your -p STATUS -p CONFIG I do not know if you have
what you think you have.
I do see you have RTCM3 in enabled on base and rover.

Unclear why you have your rover sending binary and NMEA.

There is a fait amount of data into rover USB, likely RTCM3:

Port: 3 (USB)
rxBytes 196622 txBytes 889025 parityErrs 0 framingErrs 0
overrunErrs 0 breakCond 0 reserved 257

I don't see a log of gpsd on the rover showing RTCM3, so I'm not sure
what is going in.

I'll remind you again the traditional way to do this is to connect the
output of the base serial port directly, with only wires, to an input
serial port on the rover. This would be a good test.

which works fine except the part it still returns fix.status =
Without seeing the logs of the rover, no way to know.
Still missing the gpsd logs of the rover: gpsd -nND6 /dev/ttyACM0
Uhm... Guess binary would be enough? The gpsd logs: gpsd.txt (felix@felix ~ $ gpsd -n /dev/ttyACM0 -G ntrip://root:root@ -N -D 6 &> gpsd.txt) Since I also deactivated NMEA now -> the new status/conf files. Not that they changed a lot but still: rover_conf.txt , rover_status.txt (executed "./") attachments

ubxtool.patch: contains the additions I made
Which means there are things you are not telling me, that could
also contain errors. I can't guess.
What do you mean? The file contains all changes I made to ubxtool
(added TMODE3 and RTCM3). Attachment?
Where? Not in the last two emails from you I read.

Always best to submit patches as MRs.

Hope I did it right, never worked with github/gitlab that way. It was an attachment of the mail where I wrote "ubxtool.patch: contains the additions I made" tho.

Regards Florian

Attachment: logs.tar.gz
Description: application/gzip

reply via email to

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