openBmap-locator (was Re: Ericsson releases "free" cell-id lookup API)

[Alex (Maxious) Sadleir]

2009/10/23 Baruch Even <baruch at ev-en.org>:
> Alex (Maxious) Sadleir wrote:
>> 2009/10/23 Onen <onen.om at free.fr>:
>>> Baruch Even wrote:
>>>> Alex (Maxious) Sadleir wrote:
>>
>>> As Baruch said, you must be online, and I add you must send your GSM
>>> data (and as such your position) to a third party.
>>> Local service on the phone as openBmap-locator from Baruch is the right
>>> way to go for performance, easiness, and privacy.
>> I look forward to this :)
>
> Search for openbmap-locator, it already exists. Though it's still
> somewhat limited.
I have tried it successfully but wasn't sure if you wanted to draw
attention to it yet. I did run into a couple of issues compiling on
shr-unstable (I haven't setup a crosscompiling environment yet) so I
can document the process I took here:
- when the autogen.sh asked for autoreconf, I got autoconf and
automake from angstrom (glibc)
ie.
autoconf_2.63-r0.3_armv4t.ipk
automake_1.9.6-r0_armv4t.ipk
gnu-config_0.1+cvs20050701-r5.3_armv4t.ipk
m4_1.4.8-r0_armv4t.ipk
- did not find any ipks for vala, compiled vala 0.7.7 from source
(took ages, I left it for a couple of hours and came back and it was
done so it might not actually take hours).
- automake in angstrom isn't new enough and it doesn't have the vala
macro ("warning: macro `AM_PROG_VALAC' not found in library" in
autogen.sh). compiled from source (automake-1.11) again.
- installed libsoup-2.4-1 and libsoup-2.4-dev via opkg install
- usual configure/make/make install
- run openbmap-locator in the background
- tested with mdbus -s org.openBmap.location
/org/openBmap/location/Gypsy
org.freedesktop.Gypsy.Position.GetPosition (the -s wasn't present in
the readme)

The accuracy even on the primitive algorithm was ok (still within
1-2km of actual position).
I've weighted average cell positions by max radius and signal strength
before and they "seemed" more accurate - but that technique is quite
naive anyway (sometimes a far off cell would skew the results).
Certainly, if anybody has an idea for a cell location algorithm, this
is a good app to test it with.

I also tend to get "(0, 0, 0.0, 0.0, 0.0)" sometimes when I check many
times in a row which probably isn't the fault of openbmap-locator
because looking at the FSO result for neighbouring cells at those
times returns results such as:
{   'arfcn': 77,
        'bsic': 49,
        'c1': 22,
        'c2': 22,
        'cba': 0,
        'cbq': 0,
        'cid': '0000',
        'ctype': 2,
        'foffset': 1462111,
        'lac': '0A40',
        'rac': 0,
        'roffset': 0,
        'rxlev': 24,
        'rxlevam': 2,
        'timea': 84,
        'toffset': 0}
ie. Results where the cellID = 0000 (sometimes for serving cell even
when the FR display shows full signal strength). Perhaps
openBmap-locator needs to collect a couple of results in a row if it
doesn't already.

Is there already a way to trick ogpsd into using the openbmap-locator
dbus interface? or is that still future research/improvement?

Thanks for your work so far! Thanks to Onen and Nick for keeping openBmap going!