totalueberwachung

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