I failed

February 6, 2008

After getting feedback from osso-gpsd maintainer and some more testing, I think that I was probably seeing a placebo effect with the gpsd leap-year fix — the patch does fix the leap-year bug but I  believe the fix time improvements were statistical anomalies and placebo. Bruises the ego to admit I was fooled, but that does fit the evidence best.

Not only that but in my attempt to be a responsible (non-maintainer) packager I’ve also done a mistake: I made my testing package version 1.0-25-jku0 to show that it’s not the original 1.0-25 version. This installs just fine, but later on upgrading will fail because osso-software-version depends on the exact version 1.0-25 :(

I strongly suggest everyone who installed my testing package to install version 1.0-25 from the same place (I don’t think it’s actually available from anywhere official). Like the version number implies, this is the non-patched version so your GPS time will be a day off until March. Really sorry for the trouble folks and thanks to Owen Williams for notifying me about the problem.

I’ve been playing with a possible solution to the time-to-fix problems of the Nokia N810 GPS, and it looks good: Getting a fix used to require 5-15 minutes even in very good conditions. Today I have experienced fix times between 30 seconds and 3 minutes — even from the window which was previously almost impossible.

The solution? Don’t have a 86400 second error in GPS time keeping.

I’m not kidding: there’s a leap year bug in gpsd which makes it add an extra day to all timestamps between Jan 1st 2008 – Feb 28th 2008. All gps-related code apart from gpsd is closed source so I can’t tell for sure, but I’m guessing this false time is used when the gpsdriver is initialized with the “last known position data”.

The evidence is just anecdotal, and this could be just a fluke. If anyone else wants to try and confirm, my patched testing packages are available. The first fix after installing should still take a long time, but I expect the following fixes to be faster. Please comment if you do any tests.

EDIT:  Nokia osso-gpsd maintainer says this in the bug:

The analysis that the leap year bug would affect fix times is wrong.

Based on the comments here I’m assuming it’s not just placebo that we’re all seeing, so I’ll have to investigate a bit further.

EDIT  2: Well, not only was I probably wrong, but the package prevents system upgrade. I’ve removed the patched packages and have original 1.0-25 up, please install that if you tried my patched version.

I’ve been trying to test the GPS on my newly-arrived N810. So far I have not succeeded in getting a fix from my window. Time-To-First-Fix while walking outside (with very good view of the sky) has been 5-10 minutes.

This is not what I had been hoping for. It seems I’ll still be carrying an external GPS with me, at least sometimes — just like like I have to carry a camera with me if I want to take half decent photos, even though my phone has two cameras in it. Good gadgets seem to be difficult to make. Good convergence gadgets are still, in my opinion, mostly an unproven theory.

Otherwise I’m very satisfied with the device: it feels really solid, and I’m still amazed how they fit the keyboard into a device smaller than the N800.

Not SiRF III? 

Anyway, about the GPS: There were rumours around the internet that the chipset is SiRF III, but this does not seem to be the case. Internettablettalk forum member ag2 found this string in /usr/sbin/gpsdriver:

GPS5300GPS5300GPS5300GPS5300GPS5300GPS5300GPS5300GPS5300GPS5300GPS5300GPS5300GP

GPS5300 is a gps-on-a-chip for OMAP based phones from Texas Instruments. From their product brochure (emphasis mine):

The GPS5300 NaviLink 4.0 solution enables a rapid time to first fix (TTFF) from weak satellite signals… .

Questions:

  • Can someone confirm the chipset details?
  • Assuming we do have a GPS5300 on the tablets, does “rapid” have an alternate meaning in Dallas? Maybe it’s just that everything is bigger there, even time-to-first-fix.

cool geoinfo stuff going on

November 13, 2007

Several interesting news reached my sensory organs today:

Gypsy released
Iain Holmes just released Gypsy, a more elegant GPS daemon for a more civilized time. Full API documentation, a tutorial and even experimental packages are available (shocking, I know).
Gypsy is a good match for mobile devices if you ask me, and to that end I’ve tested it with N800 and a Nokia LD-3W bluetooth GPS — works fine.

Experimental user position support for Pidgin
I haven’t tested this proof-of-concept yet, but it is interesting: Geoposition sharing for pidgin on maemo. Doesn’t use geoclue but doing so might save several hundred lines of code…

Jaiku client released with source code
Henrik Hedberg released Mauku 0.3 (Jaiku client for Maemo) a few days ago. The source code is now available at Garage. Hmm, I smell a small geoclue project here… stay tuned.

API stability? whazzat?

November 10, 2007

I haven’t posted in a while, so some news first: I’ve joined the OpenedHand crew. So far it’s been great: interesting projects, smart people and a really nice and telework-approving atmosphere (I had some doubts about working several thousand kilometers and two timezones away from the office, but it’s been very smooth so far).

For the past few days Iain Holmes and I have been reviewing the geoclue API (for those of you just tuning in: Geoclue is a geoinformation framework/library that’ll make your apps location-aware, whether on desktop, laptop or Internet Tablet). Iain posted our proposal to the mailing list yesterday. Comments on the API changes are very welcome, especially from application developers interested in using Geoclue.

I feel like I should explain why we want to change pretty much the whole API — I know it might look like NIH syndrome if you just take a quick look… So here goes:

  • First, we’re still unreleased*: if we want to change something, now is the time.
  • The way functionality was divided among interfaces did not make sense to us: One data provider may provide position, but not address info; another may provide both. It makes sense that the first one implements Position-interface and the second one implements both Position and Address. These changes will make it easier to write a master-server that could actually select different data sources based on their availability and accuracy
  • A few methods and signals had details that really needed to be changed: CivicLocation did not have timestamp on it. Position didn’t have real validity flags so it was hard to tell if a result was valid coordinate or not.
  • At this point the milk had been spilled already. The API had to break in a major way anyway, so there’s little harm in fixing the small annoyances too: CamelCasing interface, method and signal names; changing method names to more meaningful ones (like CivicLocation -> Address).

*) I do have geoclue packages available for maemo, but they’re not widely used yet, as far as I can tell. I promise to help if someone’s done a lot of work based on current API.

Summer of Code has now practically ended. I’ll post a more detailed look at my original plans and actual accomplishments soon, for now I’ll just say that I’m fairly happy with the results: some things we’re left undone, but other unplanned features got implemented. What I’m wondering is how the rest of Maemo SoC went — according to Mathieu Blondels last post he’s doing ok (although that was a month ago), but the other two projects seem to have been dropped in the mid-term evaluation.

Smoove “Instant Desktop migration” and the Ruby bindings project have had no activity at all as far as I can tell (there’s some progress on the Ruby front, but it seems unrelated). Now, a sample size of four means that we can’t draw too much conclusions, but a half-way failure rate of 50% still seems high — compare with Gnome’s 2 out of 29 = 7%. What went wrong?

Eminently employable

Conveniently at the same time as SoC ends, I’ve found out that I won’t be getting either of the two jobs I’ve applied for. Naturally the application processes took about nine weeks to finish… So, if you’re looking for a developer or development support person with any/all of these qualities (preferably around Helsinki), let me know:

  • Involved with maemo from the beginning, familiar with development on the platform
  • Understands open source tools, processes and communities
  • Experience in closed and open source development in several languages on multiple platforms
  • Lots of knowledge and hands-on expertise in Geographic Information Systems

Full time, part time, freelance — I’m not too picky as long as the job is interesting.
Contact information
LinkedIn profile

Finally got the release out the door! More information at the home page, and here’s a link to Geoclue status applet install file (for IT OS 2007) for the impatient:

ac_install_icon.png

This isn’t the major release (except for me, this being the Summer of Code evaluation release): Geoclue position API is going through some changes at the moment and the next release will probably be a lot more more interesting. Still, feedback from users and developers is very welcome!

I thought some usage advice might be nice too, so here goes: Geoclue tries to abstract the source of the data away and provide just generic location data, but unfortunately that doesn’t always work like magic (not yet at least)… Here are some tips if you’re not seeing anything useful when you select different position providers:

Hostip

  • visit Hostip with a browser and click “Make a correction” if your location is not shown or is wrong.

Plazes

  • Plazes is the most useful provider for frequently visited places with wifi. See my earlier post on why getting started with it is currently a bit difficult.

GPS

  • gps only provides coordinates, which are currently not shown on the status applet. You’ll need to use “geoclue-position-example gpsd” on the command line or try the home applet from the garage download page, if you want to see the output.
  • If you do not get any results, make sure you own a bluetooth gps device and that it’s on and paired (using Control Panel –> Bluetooth)

Resource use

I’m always worried about the resource use of things I install on my tablet and I’m pretty sure I’m not the only one, so I guess I should talk about that too:

  • geoclue position providers get started only when requested
  • currently the providers stay running indefinitely
  • CPU use is minimal, I have not observed memory use much yet