[FOSS-GPS] Re: FoxtrotGPS/libgps w/ fso-gpsd

[Timo Juhani Lindfors]

Joshua Judson Rosen <rozzin at geekspace.com> writes:
> Just from the perspective of maintainability,
> I'd really prefer to avoid supporting 3 different APIs

Indeed. Whatever the protocol is, it probably is not a good idea to
try to support multiple protocols if at all possible. Compatibility
should be provided by the APIs themselves and not each application
separately...

> Ultimately, I think what's going to happen here is that
> gpsd is going to continue fleshing-out its feature-set,
> so that it supports things like power-management
> (there are people working toward this, right now), and
> also supports every piece of GPS hardware under the sun
> (actually, it looks like this is already the case...).

That's certainly my wish too but I am not sure if I am an optimist
here ;-) I wrote down a list of things that I'd like to see in gpsd:

A way to turn the GPS on and off
================================

We probably do not want to hard code power management policy. At least
the following configurations make sense:

1) start GPS when gpsd is started and stop it when gpsd is stopped

2) start GPS when first client connects to gpsd and stop it when last
client disconnects

3) start GPS only when explicitely requested by the user and stop it
only when requested by the user.

4) Combine 2 & 3: When the first client connects, ask the user if he
wants to start the GPS or not. Similarly, when the last client
disconnects, ask the user if he wants to stop the GPS or not.

We probably do not want to hardcode the actual mechanism for turning
GPS on and off either. At least the following are all alternative ways
to do control GPS power on openmoko freerunner:

1) Poke /sys directly and hope you have the right kernel version

2) Talk to fso-frameworkd over dbus and ask it to turn the GPS on or
off.

3) Use omhacks library or the omhacks command line tools (e.g. "om gps
power 1").

Possible improvement: Support putting the chip to low power mode
instead of completely turning it off.

Save almanac and ephemeris
==========================

When GPS is turned off gpsd should save the current almanac and
ephemeris to disk. When GPS is turned on again it should send these
back to the chip if they are not too old.

Possible improvement: support reading the almanac and ephemeris from
some internet service.

> In the mean time, though, there's probably going to be some pain;
> the reason that I suggest fixing fso-gpsd is that, while it's

As I mentioned on IRC, the attached small patch adds a "-r" (=raw)
option to fso-gpsd that makes it possible to have the data flow like:

fso-ogpsd -> fso-gpsd -> gpsd -> foxtrotgps

While this may sound over complicated it is actually not:

1) it allows applications to use real gpsd

2) we can integrate the "fso-ogpsd -> fso-gpsd" part to gpsd gradually
without worrying application developers.

> One question I have, regarding GeoClue, is whether
> we'd be able to switch over to *just* using GeoClue without
> losing support for connecting to remote gpsd instances--

$ strings /usr/lib/geoclue/geoclue-gpsd | grep -i org.f
org.freedesktop.Geoclue.GPSHost
org.freedesktop.Geoclue.GPSPort
/org/freedesktop/Geoclue/Providers/Gpsd
org.freedesktop.Geoclue.Providers.Gpsd

so I kind of assume it supports remote gpsd servers.