2009/10/23 Baruch Even <bar...@ev-en.org>: > Alex (Maxious) Sadleir wrote: >> 2009/10/23 Onen <onen...@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! _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community