Future of location services on OM

[Gergely Imreh]

2009/1/11 Gergely Imreh <imrehg at gmail.com>:
> Hi,
>
> 2009/1/11 Stefan Schmidt <stefan at openmoko.org>:
>>> > 1) Start logger, listens for new GSM cell and AP updates in background.
>>> > 2) Takes the data and put it in a local storage.
>>> > 3) Syncs up to a server on user request. New data is available both on the
>>> > server and the local storage.
>>>
>>> Oh, yeah, sounds easy...  The problem is that the cell does not
>>> broadcast any location information, so the best you can do is the go
>>> around town, record the signal strength, and try to guess where the
>>> signal is coming from. If there's plain sight it is relatively
>>> straightforward. We tried it in a city - echos, shielding from
>>> buildings... imagine the rest, the signal was all over the place. Not
>>> something that one can analyse without further knowledge or guesswork.
>>>  Can send you some logs if you want to check it out
>>> Having a "cell fingerprint" database - storing relative strengths of
>>> multiple cells together with the recorded GPS position - would provide
>>> better operation, but with a cost (in storage place, for example) that
>>> is just not worth the effort. With the current GSM methods one does
>>> not aim for supreme accuracy, just speed (you can locate which
>>> intersection in a city you are in a second, not within 10+ minutes it
>>> usually takes with my GPS).
>>
>> I really thought about an easy attempt by just collecting a triple of (gsm cell
>> id, signal strength, gps position). Collect a lot of this data and try to
>> triangulate the BTS from this data. I know that reflection and other "features"
>> of a city makes this not as accurate as it could be, but I thought it may be a
>> good compromise.
>>
>> Anyway it seems you had a lot more thinking and testing about this than me.
>
> The code at http://repo.or.cz/w/CellLocator.git does just that.
> The cell_locator.py collects such GSM data.
> One can use the gsmpos/gsmfit.m Octave script to estimate the position
> of the cells.
> Put them all in cellinfo.dat, and gsmpos_server.py supplies "fake"
> coordinates by pretending to be gpsd (putting out NMEA compatible
> lines in the appropriate port).
> The whole code is rather crude, and it worked on FSO in October or so.
> I tried it with the latest testing image, and it complained about
> missing the gtk module... I haven't had time to check it in more
> detail, but i

Sorry, gmail glitch...
I haven't had time to check it in more detail, but this error probably
can be fixed easily. Though, since I didn't run it, don't know whether
any of the dbus interface methods changed since October.....

  Greg