[FOSS-GPS] Using the open GSM cell databases

Baruch Even baruch at ev-en.org
Wed Sep 23 16:20:38 EDT 2009


(This was originally sent in a private mail and replied here to be 
continued on the mailing list)

Onen wrote:
 > Hi Baruch,
 >
 > Baruch Even wrote:
 >> On Thu, 2009-09-10 at 22:05 +0200, Onen wrote:
 >>> Otherwise I am working on a D-Bus service which will offer your 
location on your phone, note/net-book etc through an embedded database. 
(If anybody is interested in this, he may contact me).
 >>
 >> I also started working on an application with a DBus interface, due to
 >> the limited APIs of the current services
 >
 > What limitations do you have exactly in mind?

The APIs currently do not allow for synchronizing the cell database to 
the user. This is the main deficit.

Other things I'd like to keep for calculations is the tav, time advance, 
  this information is only available during a phone call but it gives a 
547 meter multiplier of distance to the serving cell. It could help to 
make cell location pretty good (I mean here to process of deciding where 
the cell is location not where you are located in relation to the cell).

My user API is going to include two methods, upload and sync, the upload 
is going to include any data point that *may* be relevant and the sync 
should take a mcc/mnc pair and give you all the cell locations for that.

Obviously, the software will download information for the current 
mcc/mnc pair, it should also allow the user to specify another pair, or 
maybe just a country if the user plans to travel to that country.

I would like to make the software "just work(TM)", no need to remember 
it and maintain it. The user will install it, it will load for the first 
time, see the mcc/mnc and immediately sync to get all cell locations for 
that pair. Periodically it should try to sync with the server. The sync 
should download only the differences in the cell locations.

The server shall calculate the cell locations, I intended to implement 
several algorithms and see which one is better, but the algorithms are 
not critical, getting something to work all around is more important to 
me. The algorithms can be refined later once we have it working and have 
a user base to test them. My plan was to implement a simple cell sample 
average as a cell location and another average of all seen cells for the 
user location.

 >> I've started writing some bits of the code in Vala. I'd be happy to
 >> cooperate to get a single solution that just works for everyone.
 >>
 >
 > My service is almost ready. It is very basic though. It is written in 
Python. Nevertheless I am not strongly minded to the programming 
language, thus a shift is possible from my side.

I wanted something that works in the background on my FreeRunner so I 
wanted something that takes little memory and little CPU. Python may be 
good for prototyping but I don't like it on my FR.

 > The code is not in public repository for now, but if you need it, I 
can put more efforts in publishing it so that you may have a look at it 
as early as possible.
 >
 > Is your code available somewhere?

No. It's too early for that, since I also wanted to be able to sync I 
mostly started on the server side.

 > What are the functionalities which are implemented on your side?

For the client I only have code that collects the data for upload 
purposes so as to update the server automatically about cell information.

The plan there is to have it listen to the real GPS all the time, if 
there is a GPS signal (the user activated it) the data is collected 
every 10 seconds with the GSM and GPS info to be automatically uploaded 
to the server. This way the user both gets a location service and helps 
to update it without needing to do anything manually.

The whole thing started as an offshoot from another program I'm working 
on that automatically records gpx tracks, sets the phone into charging 
mode when it is connected to a dumb charger and is intended to do other 
things automatically so that I can just connect the FR to the car 
charger and have it work as a car gps with little work from my side.

As you can see, the automatic and "just work" is a theme for me. I have 
a problem with getting into the car and fiddling with the FR to make it 
do what I want. It should just work!

 > Where would you like to host the code? I planned to put mine under 
openBmap sourceforge website. Under a git repository.

I thought of placing it in some git repo, if SourceForge supports git 
that works for me.

I'm currently in the middle of the work on the db schema and basic logic 
to calculate cell locations using a dumb algorithm (simple averaging) 
and then I planned to implement a sync logic on the server to fetch data 
from cellhunter, simply because that's where I upload my data to, and 
then implement the sync on the server and client and then I can 
implement a simple user location algorithm and export it via a limited 
Gypsy interface.

If it will be possible to work on the server side on an existing server 
it would be much nicer, but I'd still like to have all the data I 
mentioned above (tav is notoriously missing, I think openbmap doesn't 
keep the rxlev either) and continuously (weekly basis) to sync with 
opencellid/cellhunter/openbmap to get have the largest cell database 
possible.

How does it sound to you?

Baruch




More information about the FOSS-GPS mailing list