GPS

[Daniel Willmann]

Hi,

first of all sorry for taking so long to respond. Now ogpsd is far
enough developed that I can comment better.

On Fri, 4 Jul 2008 09:16:19 +0200
Tim Niemeyer <tim.niemeyer at mastersword.de> wrote:

> * Daniel Willmann <daniel at totalueberwachung.de> [04-07-08 02:00]:
> > Right, the problem on GTA02 is if we cut power to GPS in suspend
> > we'll loose ephemeris and almanac. We need to see whether loading
> > that via UBX is sufficient enough to get away with that.
> This is really a way more specific, but let's first have some working
> peace, and later we can implement this kind of stuff.

Well, implementing this doesn't really take much more work and the
potential benefit is huge.

> > Well, due to the GPS power issues with GTA02 some form of AGPS would
> > be really good to have.
> Shure, but it is functioning without AGPS. So, as above, we should get
> something to work first, then other people have time to implement our
> software. In this time we can build AGPS or later even DGPS support.

Yeah, I agree. ogpsd is now in a state where basic functionality is
there, at least for GTA02. GTA01 is lacking somewhat at the moment as I
concentrated on the UBX protocol.
Basically for GTA01 we would need to clean up the NMEA parser a bit and
implement a UDPChannel that would receive data from gllin and take care
of starting/stopping it.

> > > Gypsy, as it is, is not what we want because the applications
> > > have to configure from where to get the GPS-Data.
> > 
> > Yeah. My plan is to have ogpsd start gllin/open a serial port as
> > defined in the frameworkd configuration and then just us the Gypsy
> > DBus Interface to convey the standard information. The more advanced
> > stuff that is possible with UBX for example will be available in a
> > device specific interface, still got to think about the details.
> Have i got this right? You will program ogpsd, wich is from client
> view exacly the same as gypsy, but without the need to define the gps
> source?

Yeah and for GTA02 (or in fact any UBX device) the gypsy interface is
almost completely implemented. There are some issues I will take up
with the gypsy developers about their interface, but generally it's
compatible. I already have a patch in the pipline where tangogps uses
the gypsy library and it works with ogpsd already.
(I need to make gypsy support optional/configurable, then I'll submit
the patch upstream)

The only part where the gypsy interface isn't implemented is with the
o.f.Gypsy.Control and Device.Start/Stop, but I hope to finish that this
weekend. After that normal gypsy apps should work without modifications.

> After this, the Application should do:
> -tell ousaged, that it want gps.
> 	-ousaged tells ogpsd to power on gps
> 		-gpsd could now do things like AGPS
> -tell gypsy, that it want gps-data (without defining the source)
> -gets data from gypsy

Yeah, that's the workflow at the moment except that the gypsy interface
is also handled by ogpsd.

> Then the implementation must be different:
> -application tells gypsy, that it want gps-data
> 	-gypsy tells ousaged, that it want gps.
> 	-gypsy tells gpsd to do things like AGPS
> 	-gypsy sends gps-data to application

We are still trying to figure out the best way to do this generically.
There are more daemons that might want to know whether power is about
to be turned off for their device so we need more interaction between
ousaged and the respective daemons.

Regards,
Daniel Willmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.linuxtogo.org/pipermail/smartphones-standards/attachments/20080726/3647bec5/attachment.pgp>