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!

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.