gpsd-users
[Top][All Lists]
Advanced

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

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


From: Benoît Thébaudeau
Subject: Re: [gpsd-users] Communication loss with GR-701W
Date: Mon, 20 May 2019 22:43:20 +0200 (CEST)

Hi Gary,

Thanks for your feedback. Greatly appreciated.

> Le 20 mai 2019 à 20:39, "Gary E. Miller" <address@hidden> a écrit :
> On Mon, 20 May 2019 18:35:35 +0200
> Benoît Thébaudeau <address@hidden> wrote:
> 
> > gpsd:IO: UBX checksum 0x1b85 over length 108, expecting 0x3030
> 
> Bad checksums are not good. Is this serial, RS-232 or USB?

USB (PL2303).

> > As you can see, after the trk tick error, the only thing still
> > working is the PPS.
> 
> Yeah, not good. Of course that error is undocumented by u-blox.

Indeed.

> > > Have you tried ubxtool to reset the configuration?
> > 
> > Is it safe?
> 
> Yes. The default config is in ROM, by design it is the safest thing
> to do.

I'll try this out then. I can dump the configuration beforehand just in case, 
anyway.

> > nor if gpsd may change this configuration on its own,
> 
> It certainly did, as shown by your logs.

What may gpsd change in the configuration? Is there any risk of getting this 
issue back after reverting the configuration to its factory defaults?

> > so I do
> > not want to risk getting a malfunction because of this.
> 
> Too late, you already have a malfunction.

Yes, I meant even worse than that (it often works fine). ;)

> > > Sending different types of reset is easy with ubxtool.
> > 
> > Sending a MON-HW2 poll (echo -ne '\xb5\x62\x0a\x0b\x00\x00\x15\x49'
> > 
> > > /dev/ttyUSB0) results in: 00000000 b5 62 0a 0b 1c 00 fa 61 0f 5f
> > > 70 00 00 00 ff ff |.b.....a._p.....|
> > > 00000010 ff ff ff ff ff ff ff ff ff ff 00 00 00 00 00 00
> > > |................| 00000020 00 00 5e
> > > 0f |..^.|
> 
> That way is to hard, I'm not even going to try to hand decode that.
> 
> And no point, UBX-MON-HW2 has nothing to do with the current issue.

The point here was only to determine whether the module could reply after it 
went silent. And this is one of the commands that can be used to get the 
internal state of the module.

> > I still have to dump the whole internal state of the module to see if
> > it reports anything abnormal.
> 
> Don't bother. Just try to configure it properly, without saving or
> resetting:
> 
> # ubxtool -d NMEA
> 
> # ubxtool -e BINARY

I will try this.

> > Sending a CFG-RST/hotstart/HWreset (echo -ne
> > '\xb5\x62\x06\x04\x04\x00\x00\x00\x00\x00\x0e\x64' > /dev/ttyUSB0)
> > makes the module recover,
> 
> Wow, you like doing things the hard way. How about:
> 
> # ubxtool -p COLD

It's just that I didn't have Python installed on my embedded system. ;)

> > I cannot succeed in duplicating the issue when stracing gpsd, which
> > may indicate that it is timing-related.
> 
> Which points again to potential serial problems. Also potential
> buffer overruns sending to the GPS at low speeds.

Makes sense. I can also give a try to 115200 Bd.

I think I got this issue on a PC too, but I have to double check this. If this 
only happens on my embedded platform, then it can be caused by a driver issue 
(PL2303 or USB root hub).

FYI, once the module has passed the critical point where it sometimes fails, 
everything seems to keep going forever. It worked fine during the whole 
weekend. Of course, after the first steps, everything gets much more quiet, so 
issues are less likely to occur too.

Best regards,
Benoît



reply via email to

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