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

[Benoît Thébaudeau]

Hi Gary,

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

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

> What serial speed are you running the GPS at?

9600 Bd.

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

> > 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. The clean fix here 
would probably be what the FIXME comment says. 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.

> > FYI, the ntp fudge time1 value that I got for the GR-701W using the
> > peerstats-based procedure is 0.181638.
> 
> Today. It will changed. Always best to make sure it is noselect.
> Otherwise it will cause problems.

Thanks for the tip.

Best regards,
Benoît