[Top][All Lists]

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

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

From: Luke Reid
Subject: Re: [gpsd-users] RAWX on u-blox F9P
Date: Thu, 11 Apr 2019 10:15:31 +1200

Thanks for the quick response.

I can rule out the serial port speed, it was 115200, but I increased to 230400 to check and same behaviour.

Attached (I hope they make it through the mailing list) are 30 seconds from the serial port directly using cat /dev/ttyS3, and gpspipe -R

In case the attachments don't make it through the mailing list, they are hosted here:

I'm using the latest version in git (release 3.19-dev, rev 3.19-dev-2019-04-10T06:21:48.007651)

The gpsd command line is (although while testing right now not using pps. -b is because I have rx only to this device)

gpsd -n -b /dev/ttyS3 /dev/pps0

Serial port is setup thus before gpsd starts (of course it changes after that):
speed 230400 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel
-isig -icanon -echo

I put a debug message at the top of the ubx_rxm_rawx function and it doesn't seem to get called.

When I use RTKLIB (the latest from Tim Everett, modified to work with F9P messages), the raw dump from the serial port decodes fine, so probably the serial port itself isn't playing up at a hardware level.

I hope this is enough info to go on, and thanks for your time on this


On Thu, Apr 11, 2019 at 7:02 AM Gary E. Miller <address@hidden> wrote:
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

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.

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

Attachment: f9p_cat_tty.raw
Description: Binary data

Attachment: f9p_gpspipeR.raw
Description: Binary data

reply via email to

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