2009/1/11 Gergely Imreh <imr...@gmail.com>: > Hi, > > 2009/1/11 Stefan Schmidt <ste...@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 _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
