[Top][All Lists]

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

Re: [gpsd-users] GPSD Client Connected to Remote GPSD - Unrecognized req

From: Joshua Quesenberry
Subject: Re: [gpsd-users] GPSD Client Connected to Remote GPSD - Unrecognized request "" when running gpsmon
Date: Wed, 6 Jun 2018 20:03:31 -0400

I've switched to a program I wrote a while ago that wraps the serial interface 
with a TCP server and I have both gpsd instances connecting to it. I started 
experimenting with this last week as a fallback and it's working fine. It's sad 
that a documented feature doesn't work and hasn't for some time / ever. My 
recommendation is that someone removes it from the documentation.

Josh Q

-----Original Message-----
From: gpsd-users [mailto:address@hidden On Behalf Of Gary E. Miller
Sent: Wednesday, June 6, 2018 4:34 PM
To: address@hidden
Subject: Re: [gpsd-users] GPSD Client Connected to Remote GPSD - Unrecognized 
request "" when running gpsmon

Yo Florian!

On Wed, 6 Jun 2018 08:29:27 +0200
Florian Petry <address@hidden> wrote:

> Also check this thread. 

Yes, it mentions a fix, but the thread does not have the fix.  Have you found a 
fix?  I'd love to have a fix that works.  I'd apply it right away.

> We also want to use gpsd in the "master/slave"  configuration, because 
> we have a flexible use case where systems are either in a lab with no 
> gps coverage with their own antenna and are using a "gps server" 
> (system with an outdoor antenna that provides gpsd with -G) or 
> outdoors where they can use real gps.

You do not need master slave to solve that.  Just have the clients inside 
coenct to the outside gpsd.  Very common configuration.

> The change can easily be managed by re-configuring the local gpsd 
> instead of configuring n client applications.

Except master/slave never, ever, worked.  I checked the git log all the way 
back.  So 'easily' becomes impossible without new code.

> And we also stumbled over the "unrecognized request" problem. In this 
> case it has nothing to do with systemd or the distro packages.

Yup.  But if we do get a working patch it will be years before some un-named 
distros pick it up. So the only solution that can work quickly is to get a 
patch for git head, and run the git head code.

> As
> mentioned, it is just a bug in gpsd and is not fixed in git head so no 
> matter what distro or init system we/you use, master/slave will sadly 
> not work atm.

Yup.  Not just atm, never worked.

> We helped ourselves with streaming gps to a UDP socket which gpsd 
> picks up fine (gps2udp).

Another, of many, easy ways to not need the master/slave mode that has never 
worked.  Maybe you can detail that solution here and get Joshua going?

Last time I dug into master/slave I also found out that the gpsd man page 
mentions specifying multiple GPS over the gpsd:// link, but there is zero code 
to support that.  That was another part of Joshua's problem.

To sum up, for Joshua to get what he wants:
    1. move to git head code
    2. add patch to make master/slave work
    3. add new code to implement multiple devices over master/slave

Since Joshua is not moving to git head (#1), no point stressing over #2, and #3 
will be a fair bit of work.  If a lost patch is found I'll apply it right away.

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

reply via email to

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