gpsd-users
[Top][All Lists]
Advanced

[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, 27 May 2020 12:00:39 -0700

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.

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

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


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

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  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: pgpmK6TiMTIyP.pgp
Description: OpenPGP digital signature


reply via email to

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