Fwd: Fwd: Re: gpsd + ubx

[Florian Kiera]

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 <florian.kiera@logicway.de> 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
> ubx_event_hook().
>
> > 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:
>
> UBX-MON-IO:
> [...]
> 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 =
> > > > 2...
> > > 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@192.168.7.101: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
> > > > 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

logs.tar.gz
Description: application/gzip