[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: Fwd: Re: gpsd + ubx
Fwd: Fwd: Re: gpsd + ubx
Tue, 2 Jun 2020 10:30:45 +0200
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!
Am 27.05.20 um 21:00 schrieb Gary E. Miller:
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.
On Wed, 27 May 2020 13:58:18 +0200
Florian Kiera <email@example.com> 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
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
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.
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.
Uhm... Guess binary would be enough? The gpsd logs: gpsd.txt
(felix@felix ~ $ gpsd -n /dev/ttyACM0 -G
ntrip://root:firstname.lastname@example.org:2101/BASIS -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 rover.sh "./rover.sh") attachments
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
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.
- Fwd: Fwd: Re: gpsd + ubx,
Florian Kiera <=
- Re: gpsd + ubx, Gary E. Miller, 2020/06/02
- Re: gpsd + ubx, Florian Kiera, 2020/06/03
- Re: gpsd + ubx, Gary E. Miller, 2020/06/03
- Re: gpsd + ubx, Florian Kiera, 2020/06/04
- Re: gpsd + ubx, Gary E. Miller, 2020/06/04
- Re: gpsd + ubx, Florian Kiera, 2020/06/05
- Re: gpsd + ubx, Gary E. Miller, 2020/06/05