pwnd by lenovo

I did't want to write anything about it. I wanted to attribute it to coincidence and bad luck, carry on with my life and forget about it, but after today I can't.

Let me tell you what happened:

02.06.2009 I try to wake my Thinkpad X200s from suspend and the backlight stays dark. Something like this happened before and was cureable by rebooting, but this time it's not. After reboot I'm greeted with the Lenovo logo - I can barely make it out if I hold the display against the light. Great. So I switch the laptop off again and let it sit there for a while without a battery, but the display stays dark. The lid switch also generates ACPI events so that is not the culprit. I guess I'll need to inform Lenovo. Luckily I got the 3 year on site service extension.
03.06.2009 09:32 I report the issue to the IBM/Lenovo ESC (electronic service call) system. Here's what I wrote:

DISPLAY BACKLIGHT STAYS DARK. DISPLAY ITSELF STILL WORKS, ONLY THE LED BACKLIGHT DOESN'T. THE LID SWITCH ALSO SEEMS TO WORK (IT CAN WAKE THE PC, SO IT'S NOT STUCK) MY GUESS: EITHER MAINBOARD OR DISPLAY (BACKLIGHT) BROKEN

A little later they call me and I'm informed that a service tech will probably be here tomorrow. So far so good.
04.06.2009 12:17 The service tech is here (was a nice guy) and he brought a replacement inverter for my CCFL. Wait, what? I bought an X200s with LED backlight. I even said so in my problem description. I provided the model number (7459-5KG) which if you [google][1] for it states it has got an LED backlight. Since I had to provide machine/model number as well as serial number I would have expected the IBM ESC system to filter out the replacement parts that do not make sense (like an inverter card for a model with LED backlight), but it seems that is not the case. (This wasn't the first time - some months ago the hook keeping the battery in place broke and they sent the wrong replacement part)
05.06.2009 20:30 Another service tech arrives - this time with the right part. After he replaced the display panel though we found out that it was cracked. Gah! So the next ETA for the repair will be Tuesday, June 9th. I'll see what fun arrives then.

I wouldn't have said anything on any individual issue. Errors do happen, that's unfortunate, but so is life. All this together though is really making me wonder whether my next laptop will still be a Thinkpad. Unfortunately I see no real alternative except maybe for one of the Toughbooks.

So if anyone is wondering why I'm not on IRC, responding to mails now you know. Hopefully on Tuesday normal operation will resume.

Posted by daniel 06/06/2009 at 00:05


Freerunner deep-sleep standby time

I've been playing around with the #1024 recamping problem for some time now, testing stuff Joerg and Dieter come up with and it seems that the latest workaround seems to address the problem (ironically enough all of Openmoko's problems seem to be solveable by increasing a capacitor). There are some other issues that surfaced during these tests, but I'm pretty sure that this is just the framework behaving badly when the calypso actually goes into deep sleep.

One thing I have asked myself over and over was if all the hassle of hunting bug #1024 was worth the gain we would have from deep-sleep. So once I've found a version of frameworkd that played somewhat nicely with the deep-sleep mode of the calypso I started measureing the battery life.

What I did was just run

 root@om-gta02 ~ $ while true; do
 > date
 > mdbus -s org.freesmartphone.odeviced /org/freesmartphone/Device/PowerSupply/battery org.freesmartphone.Device.PowerSupply.GetInfo
 > sleep 5
 > done >> battery-data

in a terminal while waking the phone occasionally. The phone crashed one evening and spent one night turned off, but I tried to compensate for that by keeping it turned on for an hour or so. I didn't use the phone except wake it up every now and then to collect data and make a phone call (at 0% capacity) to ensure that GSM was still up and running.

So here's the result:

Battery diagram

143 hours - almost 6 days worth of standby - not bad for a phone that barely lasted 6 hours in the beginning. So it seems that all the hard work in getting bug #1024 fixed really is worth it.

Unfortunately the remaining problems with deep-sleep make the phone unusable as a regular phone (as does bug #416). If you've got time please help by testing gsm0710muxd or fso-abyss and the framework with deep-sleep.

Posted by daniel 03/06/2009 at 20:23


F9N at Linuxhotel

Last weekend, from May 22nd to May 24th the freesmartphone.org and SHR communities had their first meeting, the FSOSHRUDCON. The place to hold that meeting was the Linuxhotel near Essen (more about that later).

The meeting itself was awesome! It was great to meet old friends again and finally get to know all the people that I just knew from IRC. We had some interesting talks, the crazy french guys even managed to set up a streaming server (with support from Bearstech) and I've freed about 11 phones of buzzing. And if that wasn't enough we had many inspiring talks and discussions and SHR is finally in the OE git repo.

I think everybody left the conference with renewed motivation.

I want to devote some words to the Linuxhotel as they have been a tremendous help in getting this whole event realized. The Linuxhotel is a place where seminars about open source such as Linux schooling, LPI certification, programming languages and many more take place. With this they are making money in order to finance their business.

The really cool thing however is the way they are giving back to the open source community. If you are an open source organization the Linuxhotel will offer you all their infrastructure at minimal cost. Breakfast was included, Coffee, tea and soft drinks for the whole day as well. A closet with lots of useful hardware was free for everyone to use (which basically saved live streaming since we were in need of a firewire cable. :-) You really had the impression that they are living the open source idea. I'm definitely going back there!

Posted by daniel 26/05/2009 at 15:57


7 days, 2 hours being placed on hold and 5 minutes talking to people later

Apr 22, 200923:13Leipzig - GermanyProcessed for clearance at Leipzig - Germany
Apr 22, 200923:31Leipzig - GermanyClearance delay
Apr 22, 200923:32Leipzig - GermanyClearance delay
Apr 22, 200923:40Leipzig - GermanyClearance delay
Apr 23, 200903:14Leipzig - GermanyClearance delay
Apr 23, 200907:24Leipzig - GermanyClearance delay
Apr 23, 200907:25Leipzig - GermanyClearance delay
Apr 23, 200922:03Leipzig - GermanyClearance delay
Apr 24, 200907:18Leipzig - GermanyClearance delay
Apr 24, 200908:07Leipzig - GermanyClearance delay
Apr 24, 200909:21Leipzig - GermanyClearance delay
Apr 24, 200913:00Leipzig - GermanyClearance delay
Apr 27, 200909:53Leipzig - GermanyClearance delay
Apr 27, 200909:54Leipzig - GermanyClearance delay
Apr 28, 200907:16Leipzig - GermanyClearance delay
Apr 28, 200908:46Leipzig - GermanyClearance delay
Apr 28, 200911:28Leipzig - GermanyClearance delay
Apr 28, 200911:59Leipzig - GermanyClearance delay
Apr 28, 200915:22Leipzig - GermanyClearance delay
Apr 29, 200907:14Leipzig - GermanyClearance delay
Apr 29, 200907:17Leipzig - GermanyClearance delay
Apr 29, 200910:10Leipzig - GermanyClearance processing complete at Leipzig - Germany

Posted by daniel 29/04/2009 at 10:40


Freerunner en route to Braunschweig, buzz-fix party saved

It didn't look too good for a while, but the replacement Freerunners are in the mail now. They should arrive in time unless the customs officer is having a really bad week (let's hope not :-). The tracking information currently says "Verzögerung bei der Verzollung" which means "Delayed at customs" so the coming week might prove interesting. :-)

I'm optimistic though, especially since I've already reworked 15 devices without problems.

In related news I'm thinking about getting myself a Weller WD 1000M soldering station. I've seen (and tried) this station in action at a friend's and I was pretty impressed. From standby to operational temperature in 3 seconds, auto standby when the pencil is inserted back into the rest and a short finger to tip distance make this station really pleasant to work with.

Posted by daniel 24/04/2009 at 01:03


Mail me your Freerunner (aka buzz fix)

I have now sort of streamlined the process if you want to mail me your Freerunner in order to get the buzz fixed. Please go to http://projects.totalueberwachung.de/buzz-mailin/ and follow the instructions there.

I went through all my mail and everyone who asked me directly about mailing me their Freerunner should have been issued a ticket. If I forgot anyone please accept my apology and create your ticket yourself as outlined in http://projects.totalueberwachung.de/buzz-mailin/.

Posted by daniel 19/04/2009 at 23:45


Freerunner buzz fix party in Braunschweig

It's been in the works for some time now, time to announce it here as well. :-)

From May 1st until May 3rd there will be a buzz fix party in Braunschweig. So if you have a Freerunner that is suffering from GSM buzz during calls (and more or less all devices sold until now are susceptible to buzz) then come visit us on May 1st, 2nd or 3rd.

More information here: http://wiki.openmoko.org/wiki/BuzzFixParty#Braunschweig

Please add yourself to the list if you are attending.

Posted by daniel 16/04/2009 at 13:25


FSO Tutorial (DBus rules)

So right now we have an LED on the AUX button that does nothing, lets change that! I want to be visually informed whether my GPS has a fix when I'm recording tracks, but I don't want to turn on the screen every couple seconds to check because that drains the battery (I know the LEDs are not much better on some models, but please bear with me :-).

The GPS subsystem will fire a DBus signal any time the fix is changed (No fix, 2D, 3D). The signal name is FixStatusChanged on the interface org.freedesktop.Gypsy.Device and the sole argument is an integer indicating the fix (Will be 0 if GPS is off, 1 for no fix, 2 and 3 for 2D/3D respectively).

Now lets look at the rules:

-
    trigger: DbusTrigger(system, 'org.freesmartphone.ogpsd',
        /org/freedesktop/Gypsy, 'org.freedesktop.Gypsy.Device', 'FixStatusChanged')
    filters: HasAttr(arg0, 0)
    actions: SetLed("gta02_aux_red", "dark")
-
    trigger: DbusTrigger(system, 'org.freesmartphone.ogpsd',
        /org/freedesktop/Gypsy, 'org.freedesktop.Gypsy.Device', 'FixStatusChanged')
    filters: HasAttr(arg0, 1)
    actions: SetLed("gta02_aux_red", "blink")
-
    trigger: DbusTrigger(system, 'org.freesmartphone.ogpsd',
        /org/freedesktop/Gypsy, 'org.freedesktop.Gypsy.Device', 'FixStatusChanged')
    filters: Or(HasAttr(arg0, 2), HasAttr(arg0,3))
    actions: SetLed("gta02_aux_red", "light")
-

These rules will trigger on the DBus signal 'org.freedesktop.Gypsy.Device.FixStatusChanged' from the bus name 'org.freesmartphone.ogpsd' (org.freedesktop.Gypsy will also work as ogpsd claims both) on the system bus send to the object path '/org/freedesktop/Gypsy'. If the first argument of the signal is zero (GPS turned off) the aux LED will be turned off, if it's one (searching for a fix) the LED will blink and if the argument is 2 or 3 (GPS has a fix) the LED will be on constantly.

Posted by daniel 21/10/2008 at 13:36


FSO Tutorial Part 1: GPS

So you might already know that my favourite subsystem is GPS so I'll start with that. It's also safer and more interesting than demonstrating the GSM subsystem if you're on a plane. :-)

The program I'll be using to demonstrate the functions is cli-framework, which is just a convenient way to access the DBus functions through python.

Okay, so here we go:

usageiface is a DBus Interface object which lets you access methods at a specific bus address (org.freesmartphone.ousaged), object path (/org/freesmartphone/Usage) and interface (org.freesmartphone.Usage). So let's request GPS.

root@om-gta02:~# cli-framework
freesmartphone.org interactive command line
>>> usageiface.RequestResource("GPS")
None

This command might take some time to complete because the GPS chip needs to be initialized. GPS will stay active until all requesters have either called ReleaseResource or quit.

>>> gpsposition.GetPosition()
(   dbus.Int32(7),
    dbus.Int32(1223757219),
    dbus.Double(24.3323283),
    dbus.Double(89.149197900000004),
    dbus.Double(10252.375))

This is the Gypsy DBus interface. The meaning of the parameters are: The first parameter is a bitfield specifying which fields are valid. 7 means latitude, longitude and altitude are valid.

The next fields are a timestamp, latitude and longitude and altitude which is 10km (did I mention I'm in an airplane?) You can also listen for the signals of course, but I'll just show you some of the methods.

>>> gpssatellite.GetSatellites()
[   (   dbus.UInt32(21L),
        dbus.Boolean(True),
        dbus.UInt32(20L),
        dbus.UInt32(163L),
        dbus.UInt32(34L)),
    (   dbus.UInt32(18L),
        dbus.Boolean(True),
        dbus.UInt32(41L),
        dbus.UInt32(96L),
        dbus.UInt32(27L)),
    (   dbus.UInt32(14L),
        dbus.Boolean(False),
        dbus.UInt32(53L),
        dbus.UInt32(334L),
        dbus.UInt32(16L)),
...

GetSatellites returns a list of satellite information. The first parameter is the SV id, the second tells us whether this SV is used for navigation, then follows elevation, azimuth and signal strength.

Hmm, now we want to find out our course and speed, but there's no object for that in cli-framework. As long as we know the bus name, object path and the interface we can create one ourselves:

>>> gpscourse = getInterface('org.freesmartphone.ogpsd',
      '/org/freedesktop/Gypsy', 'org.freedesktop.Gypsy.Course')
>>> gpscourse.GetCourse()
(   dbus.Int32(7),
    dbus.Int32(1223758389),
    dbus.Double(469.67170808999998),
    dbus.Double(294.69866000000002),
    dbus.Double(-1.1663066999999998))

The parameters are again validity bitmask, timestamp, speed in knots, heading and vertical speed in knots.

So this is too complicated you say? You just want to connect to gpsd and parse the NMEA sentences directly? No problem! Let's tell the framework we don't need GPS anymore.

>>> usageiface.ReleaseResource('GPS')
None

GPS will be disabled again unless some other application is using it. Now let's just try to connect gpsd style:

root@om-gta02:~# telnet localhost gpsd
r
GPSD,R=1
$GPGGA,210251.00,2533.25409,N,08517.88533,E,2,06,1.57,10225.6,M,,,,*0d
$GPGSA,A,2,21,18,14,19,22,11,05,12,32,30,06,31,2.21,1.57,1.54*06
$GPGSV,3,1,12,21,06,159,28,18,29,109,30,14,52,358,14,19,05,259,25*7e
$GPGSV,3,2,12,22,61,074,25,11,07,313,00,05,21,072,00,12,10,058,00*72
$GPGSV,3,3,12,32,05,310,00,30,27,100,27,06,02,218,24,31,57,209,35*7a
$GPRMC,210251.00,A,2533.25409,N,08517.88533,E,415.419,280.94,111008,,*07
$GPGLL,2533.25409,N,08517.88533,E,210251.00,A*02
$GPVTG,280.94,T,,,415.419,N,769.356,K*1e

Cool, it's working! I had GPS on all the time so I got a fix right away, but GPS will be enabled automatically as soon as you connect to the port. A neat little proxy fso-gpsd handles requesting and releasing the resource for you and generates NMEA sentences out of the DBus signals.

Posted by daniel 14/10/2008 at 23:46


Status of the framework

So I'm on my flight back from Taiwan now after spending three weeks at the Openmoko office in Taipei working on the FSO middleware. I believe we have made a lot of progress during that time and I'm quite happy about the general state of our middleware.

I'll give a brief overview of what we accomplished during our stay and in some later posts I will write some tutorials demonstrating the possibilities the FSO stack offers you.

  • The whole phone stack now supports the UCS2 charset. This means that sending and receiving Chinese SMS will work, as well as saving contacts with Russian names on your SIM.
  • The resource handling has been revamped completely which removes some ugly hacks in the power handling of the GSM and GPS chips. The usage daemon doesn't have any hard coded knowledge of what resources are present on a given device, Instead resources register themselves with the usage daemon. Simple resources are still handled by odeviced, more complex ones like GSM and GPS are handled by their respective daemon. Suspending and resuming the resources is also handled by ousaged.
  • All DBus calls dealing with SMS have an additional a{sv} parameter for optinal/advanced properties. At the moment this includes getting the SMSC timestamp, fields for port addressing and fields for CSM (concatenated short messages). There have also been some other changes (warning, API breakage!) in org.freesmartphone.GSM.SIM SMS related functions as we added direct sending and receiving of SMS (through org.freesmartphone.GSM.SMS).
  • Tasklets are being used by ousaged and ogsmd now, supposedly making the code flow easier to follow (I still need to understand them :-)
  • The GPS subsystem has made some really nice improvements. Quite some bugs in the warmstart path for the ublox chips got fixed which should improve the time to first fix considerably if you already have ephemeris data. There are still some quirks I need to investigate, but I believe it should be possible to get down to 10 seconds ttff easily. Also SBAS is now enabled by default and if you are lucky enough to pick up one of the geostationary satellites sending out correction data your accuracy is going to increase to 2m or better. GTA01 GPS is now also much better supported, see my last post on that.
  • The rules syntax in oeventsd changed as we try to get to a rules system that is powerful yet easy to read and understand for normal users.

Besides coding we also discussed what next issues we want to tackle, but that's something I'll mail to the mailing list (om-devel and smartphones-standards) as soon as I've had the time to write up the mail.

Let me just conclude by saying that I enjoyed the last three weeks a lot and I'm looking forward to visiting Taipei again sometime next year! :-)

Posted by daniel 12/10/2008 at 22:08