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

[Gary E. Miller]

Yo Benoît!

On Tue, 21 May 2019 21:29:56 +0200 (CEST)
Benoît Thébaudeau <address@hidden> wrote:

> > Le 21 mai 2019 à 19:45, "Gary E. Miller" <address@hidden> a écrit :
> > On Tue, 21 May 2019 18:08:11 +0200
> > Benoît Thébaudeau <address@hidden> wrote:
> >   
> > > BTW, I've discovered u-center
> > > (https://www.u-blox.com/en/product/u-center), which is a great
> > > tool too.  
> > 
> > Ugh. You can't run Python, but you can run windows?  
> 
> Not on the same machine. And I also successfully followed your tip to
> run ubxtool to communicate with the module through the embedded gpsd
> from my workstation.

Good.  A lot easier than moving the GPS around, or running WINE on 
you embedded system.

> > > I noticed the FIXME about waiting for the ACKs in ubx_cfg_prt(),
> > > so I tried the following patch as a workaround, and so far it
> > > works:  
> > 
> > Then you are overrunning the u-blox input buffer.  
> 
> Possibly, depending on its size (+ the sizes of the various
> underlying driver and hardware buffers) vs. the throughput, which I
> have not checked, but nothing seems to be failing.

You already reported the failure, so you know it was failing.

Not a driver thing.  It has to do with the slow CPU in the GPS can't
process the commands fast enough.

> > What serial speed are you running the GPS at?  
> 
> 9600 Bd.

Marginal.  Try faster, a lot faster.

> > > *   usleep(100000);
> > > count = gpsd_write(session, session->msgbuf, session->msgbuflen);
> > > *   usleep(100000);  
> > 
> > Which, of course, breaks a lot of other stuff...  
> 
> In the general case, sure, but apparently not for my specific use
> case.

It will be intermittent.  This is not new ground.

> > > Unfortunately, I do not have time to investigate this issue more
> > > deeply.  
> > 
> > I don't think that is required, we have long suspected serial
> > overrun, and your tests mostly confirm that. The only other thing
> > to try is different serial port speeds to see if that has any
> > effect.  
> 
> Unfortunately, there is no flow control mechanism available on this
> module. Slower baudrates would really be very slow, and the serial
> overrun leading to the trk tick error seems to be towards the module
> (on at least one side of the USB link), so faster baudrates would
> make things worse.

Think about it all you want, but I just beleive experimental data.

Please test.

> The clean fix here would probably be what the
> FIXME comment says.

Yes.  SiRF now waits for ACKs.  Not a simple change, but on my
TODO list.

> If the overrun is on the host side, it would also
> be possible to adjust the various serial buffer sizes, but not if it
> is on the device side.

It is on the device side.  You can use ubxtool to see that.   Or just
read the u-blox doc where it says to wait for each ACK/NACK.

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

pgpukF5nvmZaJ.pgp
Description: OpenPGP digital signature