totalueberwachung

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:

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.

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!

Apr 22, 2009	23:13	Leipzig - Germany	Processed for clearance at Leipzig - Germany
Apr 22, 2009	23:31	Leipzig - Germany	Clearance delay
Apr 22, 2009	23:32	Leipzig - Germany	Clearance delay
Apr 22, 2009	23:40	Leipzig - Germany	Clearance delay
Apr 23, 2009	03:14	Leipzig - Germany	Clearance delay
Apr 23, 2009	07:24	Leipzig - Germany	Clearance delay
Apr 23, 2009	07:25	Leipzig - Germany	Clearance delay
Apr 23, 2009	22:03	Leipzig - Germany	Clearance delay
Apr 24, 2009	07:18	Leipzig - Germany	Clearance delay
Apr 24, 2009	08:07	Leipzig - Germany	Clearance delay
Apr 24, 2009	09:21	Leipzig - Germany	Clearance delay
Apr 24, 2009	13:00	Leipzig - Germany	Clearance delay
Apr 27, 2009	09:53	Leipzig - Germany	Clearance delay
Apr 27, 2009	09:54	Leipzig - Germany	Clearance delay
Apr 28, 2009	07:16	Leipzig - Germany	Clearance delay
Apr 28, 2009	08:46	Leipzig - Germany	Clearance delay
Apr 28, 2009	11:28	Leipzig - Germany	Clearance delay
Apr 28, 2009	11:59	Leipzig - Germany	Clearance delay
Apr 28, 2009	15:22	Leipzig - Germany	Clearance delay
Apr 29, 2009	07:14	Leipzig - Germany	Clearance delay
Apr 29, 2009	07:17	Leipzig - Germany	Clearance delay
Apr 29, 2009	10:10	Leipzig - Germany	Clearance processing complete at Leipzig - Germany

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.

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/.

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.

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.

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.

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! :-)

As you may know Openmoko recently released gllin v1.1 that addresses some longstanding issues, notably: * Move the gllin binary and dependent libraries to /usr/share/gllin (was in /home/root/gllin before). There's a wrapper at /usr/bin/gllin * An init script is now available in /etc/init.d/gllin

By default this init script only enables UDP packets of the NMEA data to port 6000. Logging to file and named pipe are disabled, but you can change this behaviour in /etc/default/gllin.

For GTA01 ogpsd listens to UDP port 6000 already and now it will also start and stop gllin for you (which in turn will power the chip on/off) so GPS on GTA01 should work as seamless as it does on GTA02 (you have to install the gllin package separately, though).