Future of location services on OM

Gergely Imreh imrehg at gmail.com
Sun Jan 11 02:39:50 CET 2009


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




>
>> >> I'm just curious how much this is built into the Android code. If any
>> >> Android phone can call the mothership to get the information, why
>> >> shouldn't we be able to do that? There are unlocked Andorid phones on
>> >> sale - do they have cell-based positioning disabled??? I would wager
>> >> that it isn't....  So what is the limit if is in the Android code?
>> >> Phones sold by Google? Phones supported with Android? Any phone
>> >> running Android? Any phone running an OS based on Android?
>> >
>> > IT all comes down on service contracts on such data. I bet google has a lot of
>> > contracts for this. And you sign up a google account when using the android OS.
>>
>> What does this actually mean? They have no control over who's using
>> Android.
>
> Am I misinformed that you have to sign up to a google acount for using it? If
> yes they could make sure with this signature that you can use the data on
> Android only by contract.
>
> I did not read the EULA, nor did I work with Android so I'll stop commenting
> about it. :)
>
>> After all this discussion, I feel the wifi-based service could be done
>> much easier and more straightforward, before the GSM legal/software
>> issues are resolved.
>
> Just one thing that I did not mention yet. Wifi is pretty good in big and crowed
> cities with many apartments and offices. There it could also give you some nice
> location info inside a building.
>
> On the other hand it is really bad in small villages and on the road. Luckily
> all these data sources could be aggregated to give you the best out of all.
>
> Now to the sad side. FSO does not have the needed infrastructure for this wifi
> detection right now. We work on getting a new release of connman running so you
> have easy dbus access to these infos. It's not there yet and has to wait until
> after the MS5 release. If somebody want to start on something like this now
> using iwlist scan and or libwireless would be a temporary workaround.
>
> regards
> Stefan Schmidt
>
> _______________________________________________
> devel mailing list
> devel at lists.openmoko.org
> https://lists.openmoko.org/mailman/listinfo/devel
>



-- 
(\__/)
(='.'=)This is Bunny. Copy and paste bunny into your
(")_(")signature to help him gain world domination



More information about the devel mailing list