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: Gary E. Miller
Subject: Re: [gpsd-users] Communication loss with GR-701W
Date: Mon, 20 May 2019 14:06:51 -0700

Yo Benoît!

On Mon, 20 May 2019 22:43:20 +0200 (CEST)
Benoît Thébaudeau <address@hidden> wrote:

> > Bad checksums are not good. Is this serial, RS-232 or USB?  
> 
> USB (PL2303).

That works, but the native USB u-blox are more reliable.

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

Good luck with that.  Non-trivial.

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

Look in driver_ubx in ubx_cfg_prt().  Basically sets up a sane
BINARY or NMEA output cycle.

> Is there any risk of
> getting this issue back after reverting the configuration to its
> factory defaults?

Until we know you issue, we don't know what the risks are.  But we
do know that gpsd will try to reconfigure you GPS on startup, unless
you startup with "-b' option.  Not recommended.

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

Many ways to make it better, or worse, but factory default is always
there, and does something bacically sane.

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

And, once again, my point is that is doing things the hard way.

This is easy:

# ubxtool -p VER

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

You don't need python on your embedded system to run ubxtool.

Do it from your workstation:

# ubxtool -p VER [hostname]

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

Yup, sounds like the gpsd reconfig of the GPS is failing.  After that
gpsd does not send to the GPS.

So, try the ubxtool to reconfigure, again, after gpsd starts.

# ubxtool -e BINARY [hostname]

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

Attachment: pgp4c_RDIZRa7.pgp
Description: OpenPGP digital signature


reply via email to

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