Planet maemo: category "feed:04088ede8ecf981676b12f87999d25d2"

Alberto Mardegan

Mapper and N900 battery life

2010-04-11 16:49 UTC  by  Alberto Mardegan
In this lovely sunny Sunday I decided to pick up my bike for the first time after the winter hibernation and go for a trip around the Seurasaari bay, just next to Helsinki centre. Of course I took my N900 with Mapper with me, to make it record the GPS track into a GPX file which I will then use to geotag the photos I took with my film camera (which is a rather advanced model capable of storing the time of the pictures in its internal memory), and to visualize my track in some sports tracking website. While it will take quite some time before I'll be able to show you the pictures I took (I've just started this film roll, and I don't use this camera often), I can show you how the Mapper-generated GPX track looks like in, a sports tracking website where one can upload his own GPS tracks and get them analyzed and put into different charts:
As a geek, watching these data is enough to stimulate me to do some sports. :-)
Click to read 624 more words
Categories: english
Alberto Mardegan
Releasing a Maemo application to the Extras-devel repository is a rather simple operation, yet it can be a bit time consuming and one can always make small mistakes which, although always easily recoverable, again lead to a waste of time.

The release process typically consists of:

  1. cleaning the source tree from all unwanted files (built binary objects, editor backup copies, core-dumps and what not)
  2. building the debian package, which involves remembering the command to be used, typically something like dpkg-buildpackage -rfakeroot -sa -us -uc -i -I.git
  3. uploading the resulting files to the Maemo build robot, according to one of the methods described here
Although none of these steps is especially difficult, there are several things that can go wrong or that can make the process annoying:
  • you can easily forget to delete core dumps and other temporary files from the source tree, which might even contain sensitive information
  • remembering (or looking up in the shell history) the command for building the package
  • if you use the Extras Assistant you'll be dealing with a comfortable tool, but not as fast as the command line
  • if you have already made several releases and didn't delete the old files, you'll have to browse through them to find the latest version
The solution I've come up with is this simple script:
#! /bin/sh

set -e

BASEDIR="$(mktemp -d)"

git clone --depth 1 -l "$HOME/git/maemo-mapper"
cd maemo-mapper
git checkout origin/fremantle

dpkg-buildpackage -rfakeroot -sa -us -uc -i -I.git

cd ..
scp *.tar.gz *.diff.gz *.changes *.dsc

It's certainly not a script that you would find in a shell programming manual, but it does its job: first, it creates a temporary directory, then it clones the local git repository (which ensures that there won't be any unwanted files in the tree), then it selects the desired branch (if it's not the master branch), builds the package and uploads it to the builder. If any of these steps fail, the script terminates. Feel free to adapt it to your needs and use for your own releasing pleasure. :-)

As a side note, I've used it just now to release maemo-mapper 3.0+beta4, which doesn't include any remarkable features but comes with a redesign of the menus which are now drawn in the maemo5 style.

Categories: english
Alberto Mardegan

Fixing berserk rotations in Mapper

2010-03-16 18:53 UTC  by  Alberto Mardegan

Maemo Mapper has a nice feature which is called "automatic rotation" and consists in automatically rotating the map so that the direction you are going to is always oriented toward the top of the screen. The direction information comes from the GPS device, and applications can access it from a liblocation structure.
Unfortunately, while this value is rather reliable when you are moving fast, it's totally pointless when you are not moving: and this can be easily seen in the alpha versions of Mapper, when the map starts spinning crazily as soon as you stop moving. One thing that I didn't notice is that besides giving the direction, liblocation also gives the estimated error: the epd field in the LocationGPSDeviceFix structure represents the error on the angle, as a value from 0 to 359. In my opinion it doesn't make much sense to have an error greater than 180 on an angle, so I assume that it must be divided by two.

In the image on the right, the epd is represented by 2 × β. Now, if v⃗0is the current direction the map is oriented towards, and v⃗1 is the new direction reported by the GPS with an error (uncertainty) of β, how do we decide if (and how much) we should rotate towards v⃗1?
The algorithm I've implemented goes like this:

  • if β is greater than 90°, ignore the information altogether (i.e., don't change the rotation). Or,
  • if α (the angle between v⃗0 and v⃗1) is less than 5°, then let the map rotate to v⃗1. Or,
  • rotate towards v⃗1 by γ = α × (90 - β)⁄90, that is the rotation is limited according to the error.
I've been testing the algorithm in the last few days, and it is indeed a huge improvement over the previous situation: now the map does not rotate while I'm not moving, or it does fairly seldom. But still, the map almost always rotates once just right after stopping, and not by a small amount, which is pretty annoying as it means that most of the times when you pause you'll have the map wrongly oriented — and pauses are usually the very moment when you'd look at the map...

I'll investigate this a bit more; this means that I'll have to keep a terminal window open with a view on the syslog, while using Mapper :-)

Categories: english
Alberto Mardegan

As probably many users of Mapper have noticed, sometimes while using this application the device gets stuck for a variable amount of seconds. Even though the situation is not easy to trigger, and I've seen it myself only two or three times out of several months of development, it's still a serious problem for a device which is meant to be used also as a phone.

Unfortunately, the problem doesn't lie in Mapper itself, and there is very little I can do to work around it. I had a chance to run it on the coming PR1.2 fremantle release, and it seems not to be happening there. Anyway, as you can see from this thread and from the related poll, the preferred decision is to remove Mapper from Extras.

On the other hand, for the majority of people (at least judging from the feedback Mapper lately received) the application is quite stable, so I wouldn't like to deprive users of possible updates. For this reason, I'm going to periodically post here links to application releases; of course if you have read the paragraph above you are also aware of the potential problems of these releases (occasional freezes of your device, when using the application). I'm linking them as .deb packages, so to discourage the unexperienced user from using them. :-)

So, here we go with maemo-mapper_3.0+beta2_armel.deb. Changelog (including changelog of the previous unreleased version, too):

maemo-mapper (3.0+beta2) unstable; urgency=low

  * Fix calculation of path distances, not to include breaks.
  * If a tile is missing, try to show a scaled image from another zoom level.
  * Fix a potential out-of-array memory access.

 -- Alberto Mardegan   Sat, 13 Mar 2010 09:33:17 +0200

maemo-mapper (3.0+beta1) unstable; urgency=low

  * Add About dialog.
  * Add panel with track and route informations.
  * Remove obsolete menu items.
  * Fix "Error saving maps. Disk full?" message (see
  * Do not retry downloading of tiles if we already know it will fail.

 -- Alberto Mardegan   Fri, 12 Mar 2010 21:56:48 +0200

Happy mapping! :-)

Categories: english