Unscientific GPS note

Last week I charged the different batteries and took a GTA01 Neo, a GTA02 Neo and a Nokia N810 with me to enable their GPSes on my way home from school. Then I saved the traces they logged and loaded into JOSM to have a look (GTA01, GTA02, N810 - gpx files converted using gpsbabel from nmea)

The devices made respectively 11.28km, 12.12km and 11.07km routes (sitting in the same bag the whole time).

All in all I like the GTA01 accuracy the most although all three sometimes have horrible errors. They all three have accuracy about near the bottom line of usability for OSM mapping for a city, so if you get a GPS with that in mind, it may be slightly disappointing. All three are quite good at keeping the fix while indoor but everytime there’s not enough real input available they will invent their own rather than admit (if you had physics experiments at high-school and had to prove theories that way, you know how this works), resulting in run-offs to alternative realities - especially the N810 likes to make virtual trips. They all three apparently do advanced extrapolation and most of the time get things right, but the GTA01 GPS (the hammerhead) very notably assumes in all the calculations that the vehicle in which you move has a certain inertia and treats tight turns as errors. I’m on a bike most of the time and can turn very quickly and it feels as if the firmware was made for a car (SpeedEvil thinks rather a supertanker).

It’s suprising how well they all three can determine the direction in which they’re pointing even when not moving (the GTAs more so). The firmwares seem to rely on that more than on the actual position data sometimes. This results in a funny effect that the errors they make are very consistent even if very big - once the GPS thinks it’s on the other side of a river from you (or worse in the middle), it will stay there as long as you keep going along the river.

I’m curious to see what improvement the galileo system brings over GPS.

UPDATE: I was curious about the precision with which the altitude is reported, which can’t be seen in JOSM.  First I found that the $GPGGA sentences on my GTA01 have always 000.0 in the elevation field, but the field before it (normally containing HDOP) has a value that kind of makes sense as an altitude, so I swapped the two fields (HDOP value should be < 20.0 I believe?).  Then I loaded the data into gnuplot to generate this chart:

The horizontal axis has longitude and vertical the elevation in metres above mean sea level.  Err, sure?  I might have screwed something up but I checked everything twice.  Except the GTA01 which might be a different value completely - but the is some correlation.  I’m not sure which one to trust now.

Going into defense

Well, I’m not the kind of free software supporter that finds most pleasure in blaming a big M. corporation, author of a popular operating system, for all evil. I don’t say bad things about their software or business strategies… unless I’m asked to give my opinion.., ok, I am this kind of free software fan. But I’m trying to not be this kind of free software fan, but, well, the said corporation just makes it very hard…

I just hit an Ad banner on some news site today, that I though was funny and the Ad took me to this page. It looks like a joke page but not entirely. It manages to be funny and pathetic at the same time. I just wish they had made some funny spelling error on the front page, but no :(

ALP ctd.

I’m spending this week at GUADEC 07 in Birmingham, UK and it’s great fun so far. The theme seems to be in a big part about two things (not counting GNOME, Linux, etc.): desktop web integration and mobile Linux. One of the presentation explained that with a slide that said “Go where the money is: 1. Web, 2. Mobile”. Unfortunately a lot of the talks, especially the keynotes, talk about money-oriented development being the best thing, complying with the needs of corporate users, competing with ms-windows, and even saying deadlines help you make better code (that maybe actually true but it’s so pragmatic and put in my face). Oh well, probably that’s normal in the desktop development world, which I’m not so much into. Everything’s pragmatic here.

In the same spirit was a talk about Hiker & ALP that the ACCESS Systems people had yesterday. The presentation gave some new insight into the whole ALP thing, but not a terrible lot of it. The Hiker guys had working demos of ALP simulator (basically Xephyr) on their laptops and the presentation had a couple of screenshots.

• The look: ALP looks pretty much like PalmOS with a new, blue theme (default; there’s also a theme called Pony). The UI ideas are also taken from PalmOS but that’s probably an advantage for ALP, because that’s what PalmOS did right. The UI integrates nicely with GTK, has keypad navigation across all widgets that are on screen, and is closed-source.
• The openness: as could be expected, ALP is horribly littered with proprietary software, in fact you could say it’s a whole new proprietary OS with the Linux kernel and some free projects unnaturally fitted into it, and the Hiker part open-sourced in order to keep appearance.
• Hiker is not necessarily evil but imho it’s also not a piece of software that solves any current or serious problems of mobile computing, it’s just an alternative to a couple of other opensource frameworks for mobile apps (fortunately the Hiker authors made impression of being aware of that).
• How does it compare to them? It probably stresses security more than the other projects and has this part covered more extensively (at least the presentation had). The approach to security is definitely original but it’s hard for me to tell if it’s totally correct. The idea is that the system assumes there’s only a single user (which is not a terribly bad assumption and the existing competing mobile distros also have this assumption in a lot of places), and since then the UNIX user and group IDs would be practically unused, they are instead used for process control, i.e. different programs run with different UIDs/GIDs and that allows for easy access control like allowing different apps to use different sets of resources (like /dev nodes, iptables) and preventing e.g. malware from spreading this way. It’s cool that they thought about malware but is this approach ok? UID stands for user id after all. They mentioned a kernel patch they had sent to mainline, related to this approach, which wasn’t accepted, so maybe that’s why. One thing that’s surely positive for Hiker is the clearly defined (ripped off PalmOS) applications behaviour policy (e.g. ensuring only a single instance of most normal apps at a time, etc.), this is where OpenMoko is probably lacking.
• How does the rest of ALP compare? ALP looks much like a rewrite of PalmOS but this time based on a Linux kernel and other pieces of modern software. Unfortunately ALP is currently not yet even at the point where PalmOS left off, the implementation is just slowly caching up. It’s not any more open than PalmOS was and ACCESS is willing to go for all kind of compromises with hardware vendors and implement all those lock-ins whose avoiding is one of the objectives of a Free Phone (OpenMoko). They will also do a lot to promote their stuff, as is shown by the leaflets they handed out at their stands, full of typical marketting babble except in some places being completely untrue, rather than unclear.

There was some talk about allowing only certified apps to be used on ALP phones, depending on what the particular phone vendor decides.

The .prc loader depends on something called GarnetVM which is completely proprietary and which also in a way depends on Hiker, so probably quite useless for reusing on other devices. I was told it does load native ARM .prc’s as well as the m68k ones, although the Hiker people were not satisfied by the current compatibility level. They said it probably should run “properly written” PalmOS apps without modification, so this can mean many things. There is no connection that they know of, between their .prc loader and Palm Foleo .prc loader and compatibility layer, or any other parts of the Palm Foleo software.

ALP has the arguable advantage that it’s written with ease of making 3rd party apps in mind. There’s a set of Eclipse + CDT templates for ALP apps for everyone’s use (though they are making it sound like a whole new development environment based on opensource solutions, whenever they can) and the simulator thing (Xephyr). There’s obviously no hardware level emulation because they are not a hardware company and they don’t know what hardware ACCESS Linux will first be shipped with yet. They are looking for proposals. I saw one development phone that they use, it was a PXA running at about 300 MHz, CF and miniSD slots, 64 MB of RAM and 64 MB of Flash, a nice white case. If I guessed correctly, it had two cameras, one facing the user and one on the other side. The camera is supported under ALP. It had no touchscreen.

A Maemo person asked if they have had problems with startup times on ALP because that’s one of the things Maemo earlier struggled with and they confirmed they did and still do have problems.

It was said that they talked to Mickeyl about using Hiker in OpenMoko and Mickey liked the idea. I’m pretty sure that won’t happen before the Neo1973 release because Hiker seems to be currently even less complete than OpenMoko, also I can’t see any problem that switching to Hiker might possibly solve. Note, however, that the 0.9.1 tarball I downloaded from their site before GUADEC, was mostly a 2006 code and there must have been some progress since then. (This also shows that it’s not a normal open project because the development was going on in some internal repositories except the two released tarballs. The whole developer network (ADN) for which you have to register, also hints on palmsource.com, msdn and the likes).

Since yesterday Hiker is double-licensed under MPL and LGPL, fact that was announced during the talk.

OpenMoko to start taking orders

So around this week OpenMoko is supposed to start selling the Neo1973 developer preview (aka. Phase 1) devices. It’s hard to say if they will make it this week but either way it shouldn’t take very long now.

It just so happens there is a Phase 1 Neo1973 phone sitting on my desk and I have a couple of comments on it for those who are planning to get one for themselves too. Firstly, at least one person expressed amazement about the fact that now, three days before shipping, things like SMS support are being worked on and are nowhere near finished on the software side. Apparently it wasn’t made clear enough that this Neo1973 release is *really* a developer version and is targeted for ambitious developers who would otherwise be disappointed if the device they get comes packed with all software ready to use. And I’m sure there will be a lot more people who didn’t get it and are going to be giving OpenMoko bad reviews and this is annoying, because what they will be reviewing is not even the OpenMoko platform yet, it’s a developer snapshot. (This is similar to those folks who beg you to let them taste what you have in your pot when you’re in the middle of cooking something, and then they’ll say something about not liking the soup or worse, about your cooking skills, based on this. The thing is they are tasting a development snapshot of the soup, not the soup. It might even be poisonous, and the final dish still be perfectly fine. Guess I’m hungry…)

Another thing, when you get your device it’s a good idea to back up the factory contents of the Flash chip so you don’t lose some of the files on it before flashing an update later. Updates will overwrite all of the data in the Flash and there is a couple of files there that are not available from internet (don’t ask me why). A simple way I found to make a backup is using netcat from under Linux after it boots for the first time. It will take about 30 minutes and here’s how it’s done: connect the device to your PC with a USB cable or Bluetooth and run the following spell on the PC side:

$ for i in 0 1 2 3 4; do netcat -l -p 20000 > mtdblock$i; done

Netcat will listen for the backup data on TCP and write the five chunks (Flash partitions) to files named mtblockN in the current directory. Log into the phone through ssh and do:

# for i in /dev/mtdblock?; do cat $i | nc 192.168.0.200 20000; done

These files should be enough to restore the original state of the phone’s memory at any later time.

One more comment I have is that with the current Neo1973 kernel it doesn’t make much sense suspending and waking the system up when you’re coding something on the PC and are periodically testing it on the phone. Leave it running, power the device off entirely after you’ve finished. There’s something seriously wrong with power usage in suspend/resume. I have not made any measures and the battery I’m using is not 100% compatible but I risk to say it draws more power when suspended than when fully on. There is a curiously looking patch on the mailing lists that might explain this but I haven’t tried it yet. On the other hand I²C peripherals alone shouldn’t have that much impact.

For comparison, a different ARM-based device I own can live ~4 hours powered on and over two months suspended (i.e. with only RAM constantly on), from a full battery. The Neo will have the additional sucking from the GSM modem, but it didn’t seem to make much difference when I powered the GSM off through GPIO (assuming I did it correctly).