Re: [gpsd-users] Communication loss with GR-701W

[Gary E. Miller]

Yo Benoît!

On Fri, 7 Jun 2019 11:17:01 +0200
Benoît Thébaudeau <address@hidden> wrote:

> Le 07/06/2019 à 05:06, Gary E. Miller a écrit :
> > So.  We know:
> > 
> > The GPS UART1 input buffer is not overrunning.
> > 
> > The GPS UART1 output buffer is not overrunning.
> > 
> > The GPS UART1 input is seeing overrun errors.  
> 
> For MON-RXBUF, the protocol spec says "during the last sysmon
> period". How is this period defined?

Beats me.  We only have what u-blox gives us.  They never answer
questions.

> If there are Rx overrun errors without Rx buffer overrun errors, it
> means that some characters were received before the firmware of the
> GPS module had a chance to move the previous character from the Rx
> register to the Rx buffer, i.e. the firmware was too slow to handle
> both Rx and other tasks, which could be caused by not waiting for its
> ACKs.

That would not be the classical distinction.  Remember that each
byte in a serial bit stream has a start and stop character.  An
Rx overrun used to mean that the UART could not find those.  Often
caused by noisy lines or protocol mismatch.

Given that u-blox is not a native English speaking company you may
be correct that the terms are not being used as the RS-232 standard
defined them.

> > Seems to me a lot like a bad serial connection to UART1.  
> 
> Not really. A UART Rx works at its own baudrate, so whatever is sent
> to it, even at wrong baudrates, the Rx just cannot overrun, unless
> the Rx processing is broken or the firmware processing is too slow
> compared to the incoming flow.

Uh.  No.  The start and stop bits will not line up, that leads
to Rx overrun.

> As there is no flow control, only ACK
> monitoring can be used to mitigate this, and if it is not sufficient,
> then there is no solution because it is just an issue inside the
> firmware.

ACKs help deal with the buffer overrun, but not character overrun.

And all this assumes u-blox is using the terms as originally used
in RS-232.

> > How is the GPS UART1 connected to your host?  
> 
> The chip is a UBX-G7020 inside a Navisys GR-701W module, which uses a
> PL2303 USB interface.

If it is inside the module than nothing can be done hardware wise.

The PL2303 drivers are pretty solid, so that is likely not fixable
either.

Which is odd because the G7020 has a built in USB, but it is not being
used in your part!

    UBX-G7020_ProductSummary_(UBX-13003349).pdf

> And I get these checksum errors with any host.

As I would expect if the problem is inside the module, between the PL2303
and the G7020.

Looks like you are back to trying to rate limit the init packets from
gpsd to the GPS as you had thought that helped.  No good and final
answer yet.

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

pgpip9xlDVklu.pgp
Description: OpenPGP digital signature