GSM location service

[Baruch Even]

* Sascha Wessel <wessel at nefkom.net> [080925 15:34]:
> 
> > we are
> > currently in a fairly early stage but there is some proof of concept
> > that seems to be useful.
> 
> How do you want to calculate the position?
> Signal propagation times and cellids (not standardized) or
> some magic calculations based on signal strengths and cellids?

cellid and signal strength, I don't have signal propagation times, I can
have it for one cell only when the user is in a call but it's fairly
limited.

> Do you already have some source code?

Check out the code at http://repo.or.cz/w/CellLocator.git
Unfortunately OpenMokoForge doesn't host git projects, so the hosting is
external. We do use a project here at
http://projects.openmoko.org/projects/rocinante/

> > I would like to discuss the way we can integrate it later as a proper
> > location service.
> > 
> > The interface all applications use is the Gypsy interface
> 
> Do you mean gpsd?

Gypsy is the dbus interface used in FSO, the exact daemon that
implements it is not important to me. gpsd is the old daemon which is
being emulated by fso-gpsd for applications that weren't ported to dbus.

> > of which a
> > subset we can provide with the GSM data (there are no satellites
> > obviously).
> 
> Hmm, I can imagine how to calculate longitude, latitude and maybe
> altitude and some sort of accuracy.
> But how do you want to calculate time, hdop, vdop, pdop, heading,
> climb and speed?

I don't. lon/lat/hdop is what I aim for, hdop to give a sense of how
accurate I think my data is.

> > But currently frameworkd is implementing this interface and
> > I don't know if an interface for me to connect to frameworkd and say "I
> > am a new location service, get data from me if you don't have GPS data"
> > or something like that.
> 
> I personally think we should add a new subsystem (maybe opositiond?)
> which handles multiple providers (GPS, GSM, WLAN) like GeoClue[1].
> 
> This subsystem could also implement some sort of EnterArea/LeaveArea signals.

GeoClue seems like the pointer I needed. I'll look at it to get more
sense of it.

> > In fact, I'd like to have a low level GPS service that the GSM service
> > can use as well since part of it is collecting data to find the cell
> > towers which are later used to generate the user location even when GPS
> > is not available.
> 
> This should be doable with the current gypsy implementation.

My thought was to hijack the Gypsy interface to work with all existing
GPS programs but I guess that the real solution will be to use GeoClue
for the external interface and internally use Gypsy for real GPS data.

Cheers,
Baruch