Re: [gpsd-users] RAWX on u-blox F9P

[Gary E. Miller]

Yo Luke!

On Wed, 10 Apr 2019 19:39:08 +1200
Luke Reid <address@hidden> wrote:

> I notice in the recent git commits Gary has been doing some work
> supporting the new u-blox F9P chipset.

Trying, but hard to do without an F9P in hand.  There is new
code to do the new u-blox configuration thing, but it is not
complete, and pretty much untested.  At least until I get a
chip to play with.

> I've come across an interesting anomoly with it when recieving RAWX
> messages. For some reason it seems to not recognise it as a message,
> and it seems to confuse gpsd. Some times it switches to trimble mode,
> or NMEA mode, and occasionally jumps to 4800 baud and stops dead.

Odd.  Unknown u-blox messages should not confuse gpsd as long as
the framing (headers, length, checksum) is good.

One problem that happens is too much data for the serial port speed.
Can you confirm you are either on the native USB, or running at 115,200?

> Running gpspipe -R it will pass through other raw messages, but not
> the RAWX ones.

Odd, super-raw really means super-raw, just passing on the incoming
data.  Also sounds like serial port overflow.

Can you send a capture file?  Like "gpspipe -R -x 30 > f9p.raw"?  Or
just kill gpsd and grab the raw data from the serial port?


> I'm wondering if there is some sanity check on the length of the RAWX
> message, because they can get quite long now as the device will often
> pick up >60 sats, and have dual freq info too.

Yup.  All u-blox messages have the header, length and checksum checked
as a first pass.  But even that is after the super-raw gets passed to
gpspipe.

RAWX is decoded in driver_ubx.c.  Line 937.  The payload must be at
least 16 bytes long.  Then there are 32 byte chunks for each 
measurement.  That length is not calculated, it is assumed the
checksum would have already caught an error.

> Below is an example debug - other binary messages come through fine
> but the RAWX isn't there (confirmed it is when I capture the serial
> port directly).

Why would you expect it to be there?  It is not enabled by default.
Did you turn it on somehow?

> Below you can see one of the anomolies where it jumps
> for some reason to 4800 baud - perhaps because it's interpreting the
> binary data in some unintended way?

That usually means serial buffer overflow, and loss of lock to the
packet flow.

> Many thanks if anyone has any ideas. Happy to jump in myself to try
> to fix but wanted to see if anyone here has thoughts first.
> 
> gpsd:CLIENT: => client(0):

That snippet is way too small for me to see what is happening.  I
need at least 30 seconds of raw binary.

What does ubxtool say?  Try ubxtool with gpsd running, and standalone.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

pgpTvuViH3nfw.pgp
Description: OpenPGP digital signature