Re: [gpsd-dev] Initialization & probing questions

[Gary E. Miller]

Yo Kai!

On Mon, 26 Mar 2018 22:28:59 +0200
Kai Harrekilde-Petersen <address@hidden> wrote:

> I'm trying to implement the Skytraq driver the 'right way', going by
> the comments in driver_proto.c and referencing the Ublox driver.

Why not build on the existing Skytraq driver?  It works for Venus 6.

> 1) If I send a command, how should I wait for the response before
> returning?

You don't, can't, should not.  When you poll the GPS for stuff, it
will take a random amount of time, and output many random messages,
until it gets back to you.  Plus, consider with multiple clients and
such that you can't wait, you MUST return to the main loop.

> For example, when I'm in _proto__event_hook() with event
> == event_identified, I can probe for the firmware version, but
> getting the response back is going to take a while.

Yup, so you can not wait.

> - Will a nanosleep() for "an appropriate time" do?

Certainly not.  Return to the main loop.  Then when the message
comes in, it will be processed.  Many drivers, like the u-blox driver,
query the gpsd versions.  Look how they do it.  Just stuff the
result in subtype.

> 2) .trigger()
> It doesn't seem to much used - should I bother with it?

If you don't know you need it, then you can't code it right, so skip it.

> 3) Excessive probing time.
> Since the Skytraq powers up at 115.200 baud, it takes an obscene
> amount of time for it to be probed (as  584 sec. Yes, almost 10 min!).

Which is why we always recommend to set the GPS to the right serial
port speed before starting gpsd.

> Is there a simple way (at least during development) to cut this down
> to something more reasonable?

stty -F /dev/ttyS0 115200

> - it seems like that it always starts
> out a 4800/9600 baud, and going up in baudrate. I tried messing with
> serial.c and (trying to) disable a lot of the other GPS drivers, but
> I didn't have any luck with either.

Right, don't do that.

> 4) Store/restore of device settings.
> The skytraq allows to to probe its settings to hearts' content, which 
> allows me to restore the state when deactivating.

You could, but then that makes other things hard.  I prefer to just leave
the GPS as is on exit.  Makes debugging easier.  Opinions vary.

> Not many drivers even detect event_deactivate being fired. Should I
> bother?

I would not.

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

pgpKKsE4QbC5a.pgp
Description: OpenPGP digital signature