[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gpsd-users
Subject:    [Gpsd-users] GPSD Disconnect/Reconnect
From:       esr () thyrsus ! com (Eric S !  Raymond)
Date:       2005-03-17 23:44:08
Message-ID: 20050317234408.GA2111 () thyrsus ! com
[Download RAW message or body]

Hamish <hamish_nospam@yahoo.com>:
>             What about a /etc/gpsdrc file with which (if it exists) a
> "power user"* can specify [Lock!!!] port/mode/baud rate? This file only
> exists if you put it there, Aunt Tillie (below) is none the wiser.

That is an intelligent suggestion.  The only thing that gives me pause
about it is that the rc file parser will add some weight to the binary.
By hypothesis we'd be aiming this feature at embedded systems, so that's
a problem.

> [*] I wouldn't really call '-p /dev/ttyS1 -s 9600' "power-usage"

Yeah, but you're a geek. :-)
 
> I have never heard a suggestion of using multiple cheap GPS to get a
> better fix for where you are*.

Understood.  Attitude observation was the use case I had in mind.

> > Considering time to first  fix and the fact that you usually pay the
> > hunt-time cost only once (when you  start up your application) I don't
> > think a second and a half of hunt time is much of a price for the
> > simplification.
> 
> mmph. I'm not sold.. <devil's advocate> if the gps powers down between
> fixes, will gpsd rescan when next a connection is made?

Yes.

>                What if the gpsd process is unloaded
> when not in use, say in limited memory environments.

Same story.  It scans the indicated device every time a hotplug script 
(or equivalent) feeds it an F command.   Also rescans the current device on 
each open triggered by a client request.

Two things make this less expensive than you think.  First of all,
a lot of the time the GPS will never have been changed off the default
4800bps speed.  In that case the first attempt to sync works and there
is no hunt overhead.

Second, the one thing that is sticky is the starting baud rate.  So if
gpsd locked on a device at 9600 first time, it will try 9600 before
the normal hunt sequence on subsequent opens.  Every time it syncs up
it latches that baud rate for the next try.

So...to see any actual hunt overhead, you have to be (a) using a device
that isn't using the NMEA-standard speed, and (b) it has to be the *first
time* in the lifetime of the gpsd process that device goes active.  

On second and subsequent opens there is no hunt overhead.  Unless you're
doing stuff like swapping in GPSes with different baud rates during gpsd's
lifetime, in which case you really want the autobauding because /etc/gpsdrc
has the wrong information in it :-).

> I'd rather it just obeyed my orders of where the gps should be and
> didn't waste any more time/cycles/probing on the problem. Smart when
> needed, sure, but obedient when instructed; and as light as possible.
> K.I.S.S. works.

I hear you.  "As light as possible" doesn't cut the way you're suggesting,
though. I'd have to *add* code to bring back -s.  And throwing away autobauding
is out of the question, it's the right thing for 95%+ of the user base.

"Never needs instruction" is better than "Obedient when instructed".
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

[prev in list] [next in list] [prev in thread] [next in thread]