This morning I spent sometimes trying to understand how the GPS subsystem on the freerunner works. I’m using SHR unstable. These information might be incomplete or wrong, so just use them with a grain of salt.

Ok, at the beginning the clients where connecting to the GPS device either directly : serial device -> client or using gpsd serial device-> gpsd-> client

so far so good. In the end an application like tangogps or navit only needed to have a fix that is not that difficult to obtain from the raw device input.

But what if I want to handle and gather information from multiple GPS devices ? the idea here is to add an additional layer of indirection to make like easier to clients. On top of it, since the freerunner used dbus to communicate and frameworkd as a communication broker we have now two different players. * gps -> ogpsd -> fso-gpsd -> tangogps

From [2], this is the story: gpsd - this is our good old friend from http://gpsd.berlios.de/ “True gpsd” someone called it. ogpsd - this is a subsystem of FSO’s frameworkd. It replaces gpsd it implements the Gypsy API communicating with applications via dbus fso-gpsd - is a compatibility shim to translate Gypsy messages for applications that expect gpsd clients …

What is gypsy [3] ? Gypsy is a GPS multiplexing daemon/protocol which allows multiple clients to access GPS data from multiple GPS sources concurrently.

Now, my point was to use the GPS information collected by these two fantastic projects opencellid [5] and cellhunter [6]. In order to do that I would need to add a “fake” gps device to feed ogpsd with information retrieved from the cell database.

If the architecture I’ve described here is correct, it should not be to difficult to add the missing bit in ogpsd [4] …

UPDATE: It seems that there is already an implementation [8,9] of agps fetching data from agps.u-blox.com and based on gllin [7] , but you will need a data connection to use this one.

[8] http://www.opkg.org/package_127.html [9] http://lists.openmoko.org/pipermail/community/2008-June/018680.html

http://gpsd.berlios.de/NMEA.txt

[2] http://kerneltrap.org/index.php?q=mailarchive/openmoko-community/2008/9/24/3395094

[3] http://gypsy.freedesktop.org/wiki/

[4] http://git.freesmartphone.org/?p=framework.git;a=tree;f=framework/subsystems/ogpsd;hb=HEAD

[5] http://www.opencellid.org/

[6] http://78.47.116.33/~hole/cellhunter/

[7] http://wiki.openmoko.org/wiki/Gllin

Recently I had few problems with a svn repository that is shared between multiple ssh users. I followed the instructions in the svn book and to solve the problem once for all I recreated the repo from scratch. Briefly:

svnadmin dump SVN > /tmp/dump
mv SVN SVN-old
svnadmin create SVN
chmod -R g+rw SVN
find SVN -type d -exec chmod g+s {} \;
chown -R root.cvs SVN
 svnadmin load SVN < /tmp/dump

hopefully this is gonna work. hopefully, otherwise I guess I missing something that is very basic !

Today I’ve finished the long due migration to drupal 6 . With drupal 7 almost ready was kind of important not to stay to far behind the latest version. I’ve to say that drupal is getting better and better. This new stable version has a lot of eye candies (web 2.0 style) and improved functionalities. The update of the drupal core modules was almost painless (apart for a stupid mistake that corrupted my database…). The module upgrade took a bit more of time, but in the end I managed to get back everything I had before (and to remove a lot of old modules).

The only thing that I want to mention is about the interference of the pearwiki filter with the geshi filter for code highlighting. This is the relevant bug that contains a patch for the pearwiki module.

This is the final list of modules that I use (and upgraded):

• advanced_help
• captcha_pack
• guestbook
• pathauto
• spamspan
• views
• biblio
• cck
• pearwiki_filter
• tagadelic
• captcha
• geshifilter
• inline
• spam
• token

Arghhh today I’ve discovered reading more ...-->

a while ago I wrote about enabling the sqlite3 extension with storm . This is how you do it with the Django ORM. The collation is the same and all details are in the old post. The only tricky part is to establish the connection with cursor = connection.cursor() before calling the function to enable the extension. Failing to do so, will result in an error as the connection object will be null.

    def add_collation():
        from django.db import connection
        import sqlitext
        cursor = connection.cursor()
        sqlitext.enable_extension(connection.connection,1)
        cursor.execute("SELECT load_extension('sqlite/libcollate_debian.so')")