Location Indicator in gnome-shell

I’ve been wanting to try to write a gnome-shell extension from some time, and I ended up finding enough free time during the past weeks. So I ended up writing a gnome-shell extension which would show information about your current location as provided by your modem. Note that this information is not coming from GeoClue; the new ModemManager1 interface is not integrated yet there.

ModemManager exposes these types of information in the Location interface:

• 3GPP location, which is given as a set of 4 parameters, and specifies which is the current network cell which is giving mobile coverage to the modem:
  • MCC/MNC: Identifies the ‘mobile country code’ and the ‘mobile network code’; i.e. country and operator.
  • LAC and Cell ID: Identifies the ‘location area code’ and ‘cell id’ pair.

  Once all these items are known, a query to an open database of cell IDs can give us the exact location of the tower giving us coverage, and therefore a good approximation of where we are located.

• GPS location, given if the modem has a built-in GPS. Currently Option/HSO modems are supported, as well as QMI-powered modems with the ‘PDS’ service implemented.
• CDMA Base Station location, given as Latitude/Longitude coordinates, and available in QMI-powered modems prepared for CDMA networks. As with the 3GPP one, this location information specifies where the station giving coverage to your modem is located, which is a good approximation of where you are located.

Beware! You’ll need ModemManager >= 0.7 (i.e. git master) in order for this extension to work.

You can download and install the extension in the following link:
https://extensions.gnome.org/extension/569/location-indicator

The sources are kept in a git repository in gitorious.org:
https://gitorious.org/aleksander/gnome-shell-location-indicator

If you find the extension itself mostly useless, you may still want to take a look at the source code to see yet another example of how to talk to DBus interfaces from within gnome-shell, including the use of the new standard ObjectManager interface with a Gio.DBusObjectManagerClient.

(C) allenran917@ Flickr – CC by-nc-nd

It was something like September 2011, shortly after the last Desktop Summit in Berlin, when I started the work improving ModemManager with the new DBus API, GDBus-based DBus support, port-type-agnostic implementations, dynamic DBus interfaces, built-in org.freedesktop.DBus.ObjectManager interface support, built-in org.freedesktop.DBus.Properties.PropertiesChanged signal support, the new libmm-glib client library, the new mmcli command line tool… Took me around half a year to port most of the core stuff, and some more months to port all the plugins we had. And then, suddenly, git master wasn’t that unfinished thing any more, and we were even implementing lots of new features like GPS support in the Location interface, improved SMS Messaging capabilities, ability to switch Firmware on supported modems, and last but definitely not least, support for new QMI-enabled modems through the just officially released libqmi…

And when I thought it was all done already, I woke up from my dream and realized that not even me was really using the new ModemManager as it wasn’t integrated in the desktop… not even in NetworkManager. So there I was again, with a whole new set of things to fix…

NetworkManager integration

There is already a set of patches available to include integration of the new ModemManager interface in NetworkManager; pending for review in the NM mailing list. This is the second iteration already, after having some of the patches from the first iteration already merged in git master.

This integration is probably the most complex one in the list, as it really has to deal with quite different DBus interfaces, but the overall look of it seems to be quite good from my point of view. With the patches on, NetworkManager exposes a new –with-modem-manager-1 configure switch which defaults to ‘auto’ (compile the MM1 support if libmm-glib found). Note that both the old and new ModemManager would be supported in this case, to easier fallback to the old version if the user experiences problems with the new ModemManager.

All in all, the required changes to NetworkManager are quite well defined, implemented mainly as a new ‘NMModemBroadband’ object and some additional bits to monitor added/removed modems through the org.freedesktop.DBus.ObjectManager interface.

gnome-shell integration

A proper integration in my desktop of choice (gnome-shell based GNOME 3) required to integrate the new interface in the Network indicator of the shell. As in every good day, I first had to deal with several issues I found, but I ended up submitting a patch that properly talks to the new ModemManager1 interface when needed. As with NetworkManager, this patch would support both the old and the new interfaces at the same time.

Not that this was a big change, anyway. The Network indicator only uses the ModemManager interface to grab Operator Name, MCCMNC and/or SID, and signal strength. Something that could even be included directly in the NMDevice exposed by NetworkManager actually…

Right now the only big issue pending here is to properly unlock the modem when it gets enabled, something that I still need to check how to do it or where to do it.

Truth be told, hacking the shell has ended up being quite nice, even with my total lack of knowledge in JavaScript. My only suggestion here would be: get a new enough distribution with a recent enough GNOME3 (e.g. the unreleased Fedora 18) and jhbuild buildone from there. I think I’ve never seen a clean jhbuild from scratch succeed… maybe it’s just bad luck.

And then came the applet…

network-manager-applet integration

Why the hell would Bluetooth DUN not work with my implementation, I was thinking, until I found that even if GNOME3 doesn’t rely on nm-applet, it still uses some of its functionality through libnm-gtk/libnma, like the code to decide which kind of modem we’re dealing with and launch the appropriate mobile connection wizard. Ended up also submitting patches to include the missing functionality in network-manager-applet.

For those not using GNOME3 and gnome-shell; note that I didn’t implement the support for the new ModemManager1 interface in the nm-applet itself; I just did the bluetooth-guess-my-modem-type bits required in libnma. If I feel in the mood I may even try to implement the proper support in the applet, but I wouldn’t mind some help with this… patches welcome! Same goes for other desktops relying on NetworkManager (KDE, xfce…); I wouldn’t mind to update those myself as well, but I truly don’t have that much free time.

gnome-control-center integration

Ok, so gnome-shell integration is more or less ready now; we should be finished, right? Well, not just yet. gnome-control-center also talks to ModemManager, in this case to get Operator Name and Equipment Identifier, which btw were not getting properly loaded and updated. Once that fixed, I finally got a new patch to have the control center talk to the new interface.

Fedora 18 packages

I bet you won’t go one by one to all the patches I linked before and apply them in your custom compiled NetworkManager, gnome-shell, network-manager-applet and gnome-control-center… but for all those brave Fedora 18 users, you can try with the 64-bit packages that I built for me, all available here:

• http://www.lanedo.com/~aleksander/fedora-packages/20121112/

If you want to rebuild these packages yourself, you’ll find the source tarballs here and the packaging repositories here. The packaging is really awful – I suck at it – so you’ll probably need to install the RPMs with –force Note that the git repo for packaging has several git submodules, one for each item packaged, so remember to “git submodule init” and “git submodule update“.

We done yet?

Are these all the patches needed to have the best ModemManager experience in GNOME3? No! The list of pending tasks for this purpose grows a bit every day…

• Common code to parse the mobile broadband providers database, exposed in libnm-gtk and used by the wizard, the control center and the shell
• Link mobile connection profiles to a specific SIM/modem
• Ensure modems are PIN-unlocked when they get enabled
• Rework the logic behind the Network indicator in gnome-shell, trying to make it easier to connect to a default connection profile. The same logic would then be need to be applied to the control center…
• Proper IPv6 support in mobile broadband connections
• Connection profiles with multiple APN/bearers
• SMS messaging
• Location information integration
• An independent UI application to manage advanced settings in ModemManager?
• …

Help!

Thanks

Special thanks go to my employer Lanedo GmbH, which sponsors quite a lot of the GNOME integration work; as well as to my girlfriend’s employer, which sends her 400km away from home from Monday to Thusday. Without them this job would have been impossible!


Filed under: Development, FreeDesktop Planet, GNU Planet, Lanedo Planet, Planets Tagged: fedora, gnome, gnome-control-center, gnome-shell, libqmi, ModemManager, NetworkManager, rpm ]]> http://sigquit.wordpress.com/2012/11/13/integrating-the-new-modemmanager-in-gnome3/feed/ 4 drehbahn 6483141309_d02fb18a50_z http://sigquit.wordpress.com/2012/09/14/sms-goodies-in-modemmanager/ http://sigquit.wordpress.com/2012/09/14/sms-goodies-in-modemmanager/#comments Fri, 14 Sep 2012 10:46:36 +0000 aleksander http://sigquit.wordpress.com/?p=488 ]]>

(C) josullivan.59 @ Flickr – CC by-nc-sa

Lots of new SMS-related features have landed in ModemManager this week, and as I have as much memory as a fish used to have, I need to write down all the commands I’ve used to test all this; hence this post.

Note that all the stuff I talk about here applies to both AT and QMI based modems.

 

Multiple storages

The current stable 0.5/0.6 releases will only use the core/plugin defined ‘default’ storages for reading and sending short messages. This means that if you happen to have stored SMS in another non-default storage ModemManager won’t show them to you.

In the new 0.7 codebase, ModemManager reads the messages from all the available storages. It is able to read not only DELIVER-type PDUs from received SMS, but also SUBMIT-type PDUs from user-created SMS which got stored. The “Sms.Store()” method in the interface now allows (optionally) specifying in which storage the SMS should be kept.

The following commands allow to create a new SMS and store it in the “sm” (SIM) storage:

$> sudo mmcli -m 0 \
              --messaging-create-sms="text='Hello world',number='+1234567890'
Successfully created new SMS:
    /org/freedesktop/ModemManager1/SMS/21 (unknown)
 
$> sudo mmcli -s 21 --store-in-storage="sm"
successfully stored the SMS
 
$> sudo mmcli -s 21
SMS '/org/freedesktop/ModemManager1/SMS/21'
  -----------------------------------
  Content    |              number: '+1234567890'
             |                text: 'Hello world'
  -----------------------------------
  Properties |            PDU type: 'submit'
             |               state: 'stored'
             |                smsc: 'unknown'
             |            validity: '0'
             |               class: '0'
             |             storage: 'sm'
             |     delivery report: 'not requested'
             |   message reference: '0'


Note that you can create, store and send SMS objects regardless of what storage you’re using for each, ModemManager will take care of properly synchronizing the access to each of them.

The Messaging interface also defines new properties to list all the supported storages and to specify which is the default storage being used for received messages (and for stored ones when no specific one given in “Sms.Store()“):


$> sudo mmcli -m 0 --messaging-status
/org/freedesktop/ModemManager1/Modem/0
  ----------------------------
  Messaging | supported storages: 'sm, me'
            |    default storage: 'me'


 

Text multipart SMS

We support receiving text multipart messages in ModemManager since some stable releases ago; but support for sending multipart messages was still missing. Not any more! Roberto Majadas of OpenShine started this work some months ago with a patch for MM 0.6, which I took over and ported to git master and the new 0.7 codebase.

Of course, we support both the default GSM 7-bit alphabet, as well as UCS-2:

• GSM 7 encoded multipart messages: If the message is less or equal than 160 septets a singlepart SMS will be used; otherwise the input text will be split into chunks of 153 septets and sent as a multipart message.
• UCS-2 encoded multipart messages: The GSM 7 alphabet and its extensions are not enough to cover all scripts available out there. Luckily, we can send PDUs with UCS-2 encoded text (UCS-2 covers all the basic plane of Unicode, and is equivalent to UTF-16 in that range). When using this encoding, if the input text is less or equal than 70 UCS-2 characters (140 bytes) a singlepart SMS will be used; otherwise the input text will be split into chunks of 67 UCS-2 characters (134 bytes) and sent as a multipart message. Note anyway that this doesn’t mean that we only allow 70-byte long input strings to fit into a singlepart message; as the conversion from the input UTF-8 text to UCS-2 isn’t always increasing the required number of bytes. As an example, we can now send 210 bytes of UTF-8 encoded chinese text into a single SMS with 140-bytes of UCS-2.

Note that from the API user’s point of view, the SMS objects are not considered multipart or singlepart; that is taken as internal information only required for the PDU-based implementation.

Multipart messages can be created by writing a long enough ‘text‘ value passed in the ‘--messaging-create-sms‘ command, as shown before.

 

Raw data multipart SMS

In addition to text short messages we now also properly support raw binary data singlepart and multipart messages (reported as 8bit encoded). This means that both the sender and receiver can agree in any text encoding to be used between them, or even send in one or more SMS whatever raw binary stream you have.

The ‘mmcli’ command line utility was improved with several commands to test this feature. For example, you can now send using just SMS messages whatever file you have in your system, just doing:

$> sudo mmcli -m 0 \
       --messaging-create-sms="number='+1234567890'" \
       --messaging-create-sms-with-data=/path/to/your/file
Successfully created new SMS:
    /org/freedesktop/ModemManager1/SMS/22 (unknown)
 
$> sudo mmcli -s 22 --send
successfully sent the SMS


When the receiver gets all the parts of the message, she can now recover the sent file with another ‘mmcli’ command in her ModemManager setup:

$> sudo mmcli -m 0 \
              --messaging-list-sms
Found 1 SMS messages:
    /org/freedesktop/ModemManager1/SMS/0 (received)
 
$> sudo mmcli -s 0 \
              --create-file-with-data=/path/to/the/output/file


But beware! The file is sent in chunks of 134 bytes, and there is a maximum of 255 parts in a given multipart SMS, so this leaves you with a maximum size of around 33 Kbytes And not only that, if you’re paying e.g. 0.10€ for each SMS sent, you would be paying more than 25€ for those 33 Kbytes. Yes, needless to say, this is therefore the most useless use case ever. But still, works as a proof of concept.

 

Delivery reports

Last and least, you can now also request delivery reports when sending an SMS, by passing the ‘delivery-report-request=yes‘ key/value pair in the ‘--messaging-create-sms‘ command.


$> sudo mmcli -m 0 \
           --messaging-create-sms="text='你好',\
                                   number='+1234567890',\
                                   delivery-report-request=yes"
Successfully created new SMS:
  /org/freedesktop/ModemManager1/SMS/0 (unknown)
 
$> sudo mmcli -s 0 --send
successfully sent the SMS
 
$> sudo mmcli -m 0 --messaging-list-sms
Found 21 SMS messages:
  /org/freedesktop/ModemManager1/SMS/0 (sent)
  /org/freedesktop/ModemManager1/SMS/1 (received)
 
$> sudo mmcli -s 1
SMS '/org/freedesktop/ModemManager1/SMS/1'
  -----------------------------------
  Content    |              number: '+1234567890'
  -----------------------------------
  Properties |            PDU type: 'status-report'
             |               state: 'received'
             |                smsc: '+9876543210'
             |            validity: '0'
             |               class: '0'
             |             storage: 'unknown'
             |   message reference: '137'
             |           timestamp: '120914120619+02'
             |      delivery state: 'temporary-error-sc-specific-reason' (0x30)
             | discharge timestamp: '120914120619+02'


You can then match the delivery report with the message sent by using the ‘message reference‘ value, which should be the same in both. This also applies to multipart messages, where the ‘message reference’ of our SMS object is the one reported when sending the last part, and therefore we only request the delivery report in the last part sent.

Enjoy!


Filed under: Development, FreeDesktop Planet, GNU Planet, Lanedo Planet, Planets Tagged: mmcli, ModemManager, NetworkManager, QMI, SMS ]]> http://sigquit.wordpress.com/2012/09/14/sms-goodies-in-modemmanager/feed/ 0 drehbahn Fish memory http://sigquit.wordpress.com/2012/08/20/qmi-powered-broadband-connections-in-openwrt/ http://sigquit.wordpress.com/2012/08/20/qmi-powered-broadband-connections-in-openwrt/#comments Mon, 20 Aug 2012 10:53:56 +0000 aleksander http://sigquit.wordpress.com/?p=477 ]]> Linux 3.2 kernel with QMI support

When I started to develop the QMI support in OpenWRT, latest trunk was based on the 3.2 kernel series. By the time you read this, OpenWRT may already have a recent enough kernel (>= 3.4), so this custom setup may not be needed any more, so keep it just for reference.

The ‘v3.2.5-qmi’ branch in the Lanedo stable kernel tree contains a set of patches on top of the 3.2.5. Linux kernel release. These patches add support for QMI ports (updated ‘cdc-wdm’ and new ‘qmi_wwan’ driver) in the 3.2 stable series:
git://gitorious.org/lanedo/linux-stable.git

 

OpenWRT with QMI support

The same set of patches was then added to the ‘qmi-support’ branch of the Lanedo openwrt tree, enabling OpenWRT builds with QMI support:
git://gitorious.org/lanedo/openwrt.git

When you compile this OpenWRT build, make sure you configure the kernel with the QMI-specific requirements enabled:

CONFIG_PACKAGE_kmod-qmi-wwan=m
CONFIG_PACKAGE_kmod-usb-wdm=m
...


For reference, you can find here the .config I used for the ar71xx-nand builds (installable in a RouterBoard 433UAH).

 

libqmi-glib and qmi4g

‘libqmi-glib’ and ‘qmi4g’ are two new packages added to the ‘qmi-support’ branch of the Lanedo openwrt-packages tree:
git://gitorious.org/lanedo/openwrt-packages.git

This repository can be added to your OpenWRT build by creating a new ‘feeds.conf‘ with the following contents:
src-git packages git://gitorious.org/lanedo/openwrt-packages.git;qmi-support

The new packages, in detail:

• libqmi-glib: This package provides a preliminary version of libqmi-glib, as released unofficially by me. This package will provide the libqmi-glib library, the qmicli command line utility and the qmi-network script.
• qmi4g: This package registers a new ‘qmi4g‘ network protocol, which takes care of launching the network start/stop requests through QMI.

If you’re using the precompiled OpenWRT images I gave above, you can just install these packages using ‘opkg’ once you’ve added the ‘latest’ Lanedo repository.

 

Configuring qmi4g

Once the qmi4g package is installed, you are then allowed to include the
following configuration under /etc/config/network:

config 'interface' 'broadband'
option 'ifname' 'wwan0'
option 'proto' 'dhcp'
option 'auto' '0'

config 'interface' 'wdm0'
option 'proto' 'qmi4g'
option 'wdmif' '/dev/cdc-wdm0'
option 'wwanif' 'broadband'


The configuration is split into 2 interfaces:

1. First, the configuration for the ‘wwan0‘ interface. This interface needs to be set with ‘auto‘ equal to ‘0‘, so that it is never brought up automatically; and with ‘dhcp‘ as the protocol to be used. You should never ifup/ifdown this interface manually.
2. Second, a virtual interface using the new ‘qmi4g‘ protocol, which needs 2 options set: ‘wdmif‘ with the cdc-wdm port to use for the QMI protocol, and ‘wwanif‘ with the uci-interface-name of the wwan iface to use.

 

Start/Stop the network

Once the qmi4g setup is added in /etc/config/network, you can now then just:
$> ifup wdm0

That command will internally first launch the network start QMI command, and if succeeds it will itself ifup wwan0. The wwan interface can be used as any other eth-based interface now, it can be added as part of multiwan or in a vlan or in a bonding, or anything.

Once the connection is no longer wanted, you can just:
$> ifdown wdm0

That command will stop the network with QMI and also ifdown wwan0.

 

LUCI

Once the network configuration is in place, the connection can also be started via web. Just log in to LUCI, go to Network interfaces and you’ll see both the wwan interface (“broadband“) and the virtual “wdm0“. Starting/Stopping the “wdm0” interface via LUCI should work. As said before, you shouldn’t touch the wwan interface directly.

Enjoy!


Filed under: Development, FreeDesktop Planet, GNU Planet, Lanedo Planet, Planets Tagged: libqmi, linux, openwrt, qmi4g ]]> http://sigquit.wordpress.com/2012/08/20/qmi-powered-broadband-connections-in-openwrt/feed/ 44 drehbahn http://sigquit.wordpress.com/2012/06/25/gnome-asia-2012/ http://sigquit.wordpress.com/2012/06/25/gnome-asia-2012/#comments Mon, 25 Jun 2012 15:08:43 +0000 aleksander http://sigquit.wordpress.com/?p=463 ]]>

Finally back home after attending GNOME.Asia 2012 and some vacation time afterwards.

 



CC BY-NC-SA 2.0, Sammy Fung

The conference started on Friday afternoon, with a design workshop managed by Allan Day, Jakub Steiner and William Jon McCann. It was pretty interesting, truth be told, and I particularly enjoyed how Jakub played with Inkscape to create the icon of “GNOME Ball” (now we just need a program for the icon). I truly want to spend more time with Inkscape now, and try to draw something better than my previous attempts to draw an icon/logo.

 



CC BY-NC-SA 2.0, Sammy Fung

I gave two talks during the first day of the conference, one about Tracker (slides here) and another one about ModemManager (slides here). The talks were recorded, but official videos of the talks are not yet available on the Internet.

 



Thanks to the usual jet lag, I also found time to develop the application-menu support for Devhelp during my stay in Hong Kong. The code is currently available in the ‘application-menu’ branch in the gnome git repo, and tracked at GB#677927.

 



Finally, thanks to my employer, Lanedo GmbH, for sponsoring my attendance to this great conference!


Filed under: FreeDesktop Planet, GNU Planet, Lanedo Planet, Meetings, Planets Tagged: devhelp, gnome, gnome-asia, ModemManager, tracker ]]> http://sigquit.wordpress.com/2012/06/25/gnome-asia-2012/feed/ 0 drehbahn gnome-asia Design workshop Tracker talk Devhelp Application Menu Lanedo Logo http://sigquit.wordpress.com/2012/06/06/looking-for-a-modemmanager-logo/ http://sigquit.wordpress.com/2012/06/06/looking-for-a-modemmanager-logo/#comments Wed, 06 Jun 2012 11:11:40 +0000 aleksander http://sigquit.wordpress.com/?p=458 ]]> Hey designers!

ModemManager (a.k.a “MM“) is a small daemon which takes care of controlling your broadband devices in your GNU/Linux system. We currently don’t have a logo for ModemManager, so if you’re a designer with some free time, share your ideas! Something simple, similar to the NetworkManager logo would be great, actually.


Filed under: Development, FreeDesktop Planet, GNU Planet, Lanedo Planet, Planets Tagged: ModemManager, NetworkManager ]]> http://sigquit.wordpress.com/2012/06/06/looking-for-a-modemmanager-logo/feed/ 4 drehbahn http://sigquit.wordpress.com/2012/05/22/speaking-at-gnome-asia-2012-hong-kong/ http://sigquit.wordpress.com/2012/05/22/speaking-at-gnome-asia-2012-hong-kong/#comments Tue, 22 May 2012 18:22:24 +0000 aleksander http://sigquit.wordpress.com/?p=452 ]]> Only 3 weeks left for GNOME.Asia, this year in the beautiful city of Hong Kong.



According to the current schedule I’ll be giving two talks on Saturday June 9th:

• An introduction to Tracker, SPARQL and whatnot:
  Tracker is not (only) a search engine: it is a semantic data storage, powered by RDF ontologies, Nepomuk, and the SPARQL protocol. Tracker is one of the core building blocks of the MeeGo Harmattan operating system; and since release 2.30, it is also a blessed external dependency in GNOME. But it wasn’t until GNOME 3 and the first release of GNOME Documents that it started to get some really good attention… and there is more to come!
• ModemManager revamped: now supporting LTE/4G modems:
  ModemManager, along with NetworkManager, provides easy-to-use broadband modem connections in the GNOME desktop. With new requirements coming along with the new LTE (4G) communication standards, ModemManager got not only a face-lift, but also a deep surgery to improve its codebase and the way it supports vendor-specific plugins.

  The new ModemManager comes with a new GDBus-powered interface; built-in support for LTE and mixed CDMA+LTE devices; dynamic interfaces and per-interface state machines; helper libmm-common and libmm-glib libraries; a handy “mmcli” command line interface utility; and a new plugin development strategy which is port-type agnostic and based on GIO async calls.

  This talk is an introduction to ModemManager, with special focus on LTE and all the new details and features coming with the new codebase.

Thanks to my employer, Lanedo GmbH, for sponsoring my attendance!


Filed under: FreeDesktop Planet, GNU Planet, Lanedo Planet, Meetings, Planets Tagged: gnome-asia, ModemManager, tracker ]]> http://sigquit.wordpress.com/2012/05/22/speaking-at-gnome-asia-2012-hong-kong/feed/ 0 drehbahn gnome-asia http://sigquit.wordpress.com/2012/03/29/enabling-gps-location-in-modemmanager/ http://sigquit.wordpress.com/2012/03/29/enabling-gps-location-in-modemmanager/#comments Thu, 29 Mar 2012 09:33:40 +0000 aleksander http://sigquit.wordpress.com/?p=431 ]]> Location information in ModemManager

Since MM 0.5 at least, ModemManager comes with a Location interface which is defined to expose not only 3GPP-specific location information (operator MMC/MNC + Location area code + Cell ID), but also GPS-specific location information (cached NMEA traces and raw location information). In MM 0.7, this Location interface will actually work for GPS location, at least for Option modems with GPS capabilities.

The HSO plugin

The High-Speed Option plugin is probably one of the most complex plugins being handled in ModemManager. In the new ModemManager 0.7 codebase, HSO modems (MMBroadbandModemHso) are implemented as a subclass of the standard Option modems (MMBroadbandModemOption), as they share lots of common features (allowed modes management, access technology and signal quality reporting…); but they also implement lots of connection related HSO-specific features (e.g. success of a connection establishment gets notified via unsolicited messages), which are most of them handled in a new HSO-specific bearer. Some of these advanced Option modems come with additional surprises: GPS-specific ports (AT port for control, raw serial port for NMEA traces).

The HSO modems provide detailed information about the type of each port being exposed in the USB interface; and so during the probing phase we are able to easily grab the GPS-control AT port and the additional serial port for NMEA traces (handled by a new MMGpsSerialPort port type). Once the HSO modem knows it has these two ports, it will allow to enable or disable any of the two GPS-specific location sources (NMEA or raw), or both at the same time. The NMEA location source will enable the modem to expose the last cached NMEA traces; while the raw location source will tell the modem to just expose generic location information such as time, latitude, longitude and altitude. In the case of the HSO modem (and possibly in every other case), both location sources are actually implemented based on the same NMEA traces received (raw information is parsed from $GTGGA traces). In addition to the core GPS location handling and the HSO-specific implementation, libmm-glib and mmcli where also improved to easily play with the new features.

Trying the GPS location retrieval with your Option modem

If you want to give a quick try to these capabilities, grab ModemManager git master, compile, install and plug in your modem. You first need to check whether the modem has GPS-specific location capabilities. Note that we’ll assume the modem is exposed as index 0; if you have more than one modem, just use --list-modems to check the proper modem index:

$ mmcli -m 0 --location-status
/org/freedesktop/ModemManager1/Modem/0
  ----------------------------
  Location | capabilities: '3gpp-lac-ci, gps-raw, gps-nmea'
           |      enabled: 'none'
           |      signals: 'no'


The output says that the modem supports 3GPP Location area code/Cell ID, GPS raw and GPS-NMEA location sources. None is enabled yet, as we didn’t enable the modem, which we can do issuing:

$ sudo mmcli -m 0 --enable
successfully enabled the modem

$ mmcli -m 0 --location-status
/org/freedesktop/ModemManager1/Modem/0
  ----------------------------
  Location | capabilities: '3gpp-lac-ci, gps-raw, gps-nmea'
           |      enabled: '3gpp-lac-ci'
           |      signals: 'no'


The 3GPP location source will always be enabled by default if it is supported by the modem, while the GPS-specific ones will always be disabled by default. The reasoning behind this is that the 3GPP LAC/CI comes for free in C(G)REG notifications when C(G)REG=2 is supported, while the GPS location is usually an additional module in the modem, with high power consumption. Using mmcli, we can now enable both GPS raw and NMEA location sources:

$ sudo mmcli -m 0 \
             --location-enable-gps-raw \
             --location-enable-gps-nmea
successfully setup location gathering


If we do check again the status, we’ll see the GPS-specific locations are enabled:

$ mmcli -m 0 --location-status
/org/freedesktop/ModemManager1/Modem/0
  ----------------------------
  Location | capabilities: '3gpp-lac-ci, gps-raw, gps-nmea'
           |      enabled: '3gpp-lac-ci, gps-raw, gps-nmea'
           |      signals: 'no'


Once they are enabled, ModemManager will start receiving NMEA traces in the GPS raw port, and will start to cache and process them. mmcli allows to show location-source-specific information with --location-get-3gpp, --location-get-gps-nmea and --location-get-gps-raw; but it also allows to query for all at the same time:

$ sudo mmcli -m 0 --location-get
/org/freedesktop/ModemManager1/Modem/0
  -------------------------
  3GPP location   | Mobile country code: '214'
                  | Mobile network code: '3'
                  |  Location area code: '21071'
                  |             Cell ID: '7033737'
  -------------------------
  GPS NMEA traces | $GPGGA,,,,,,0,,,,,,,,*66
                  | $GPRMC,,V,,,,,,,,,,N*53
                  | $GPGSA,A,1,,,,,,,,,,,,,,,*1E
                  | $GPGSV,4,1,16,24,,,,29,,,,05,,,,18,,,*7A
                  | $GPGSV,4,2,16,22,,,,14,,,,11,,,,17,,,*7B
                  | $GPGSV,4,3,16,03,,,,12,,,,30,,,,13,,,*78
                  | $GPGSV,4,4,16,23,,,,15,,,,27,,,,07,,,*79
                  | $GPVTG,,T,,M,,N,,K,N*2C
  -------------------------
  Raw GPS         | Not available


Note that ModemManager will expose only the last received NMEA traces of each kind, except for those ($GPGSV here) that are actually building a sequence.

Once the GPS module fixes a position, we’ll process the $GPGGA NMEA trace to get valid GPS location information:

$ sudo mmcli -m 0 --location-get-gps-raw
/org/freedesktop/ModemManager1/Modem/0
  -------------------------
  Raw GPS         |  UTC time: '155142.2'
                  | Longitude: '-3.513941'
                  |  Latitude: '40.502603'
                  |  Altitude: '18.000000'


What about other modems?

Well, if the modem exposes GPS-specific ports in the same USB interface, it shouldn’t be difficult to add support for them, specially now that all the core/libmm-glib/mmcli work is already available.

A special case is when the modem exposes a single AT port via USB and the GPS port via RS232 (e.g. Sierra Wireless FXT009 with GPS extension). This case is a bit more tricky as there is no easy way for ModemManager to tell that the RS232 port is to be managed by the same modem object created after grabbing the AT port. In this case, the user may need to explicitly set some magic udev tags to let ModemManager handle the needed logic, but that also may get tricky if the user has more than one such modem plugged in (not sure for what, but anyway).


Filed under: Development, GNU Planet, Lanedo Planet, Planets, Programs Tagged: gps, location, ModemManager, NetworkManager, option ]]> http://sigquit.wordpress.com/2012/03/29/enabling-gps-location-in-modemmanager/feed/ 3 drehbahn http://sigquit.wordpress.com/2012/03/02/help-wanted-in-modemmanagernetworkmanager-development/ http://sigquit.wordpress.com/2012/03/02/help-wanted-in-modemmanagernetworkmanager-development/#comments Fri, 02 Mar 2012 13:02:41 +0000 aleksander http://sigquit.wordpress.com/?p=417 ]]> If you have free time, and experience with gtk-doc documentation or man pages, ModemManager developers will thank you [1] if you help writing the new libmm-common, libmm-glib and mmcli documentation:
[MM 0.6] Documentation

If you have free time, basic GLib/GIO development knowledge, and a broadband modem (either USB dongle or internal) to play with, ModemManager developers will thank you [2] if you port any of the missing plugins to the new codebase in the 06-api branch:
[MM 0.6] Plugins

If you have free time, NetworkManager installed [3] and basic GLib/GIO development knowledge, ModemManager developers will thank you [4] if you help providing support for the new ModemManager1 interface in NetworkManager:
[MM 0.6] NM integration

[1] You’ll get one beer for free if we ever meet.
[2] You’ll get two beers for free if we ever meet.
[3] This already leaves out Jose, Luca and Alfred.
[4] You’ll get three! beers for free if we ever meet.


Filed under: Development, GNU Planet, Lanedo Planet, Planets Tagged: glib, gobject, ModemManager, NetworkManager ]]> http://sigquit.wordpress.com/2012/03/02/help-wanted-in-modemmanagernetworkmanager-development/feed/ 1 drehbahn http://sigquit.wordpress.com/2012/02/08/fosdem-talk-slides-online/ http://sigquit.wordpress.com/2012/02/08/fosdem-talk-slides-online/#comments Wed, 08 Feb 2012 11:28:07 +0000 aleksander http://sigquit.wordpress.com/?p=412 ]]> The slides of my talk about LTE and ModemManager in FOSDEM are now online at the Lanedo articles website:
• LTE is here and ModemManager is (almost) ready for it

Filed under: GNU Planet, Lanedo Planet, Meetings, Planets Tagged: FOSDEM, LTE, ModemManager, slides ]]> http://sigquit.wordpress.com/2012/02/08/fosdem-talk-slides-online/feed/ 0 drehbahn http://sigquit.wordpress.com/2012/01/30/fosdem-2012/ http://sigquit.wordpress.com/2012/01/30/fosdem-2012/#comments Mon, 30 Jan 2012 20:54:07 +0000 aleksander http://sigquit.wordpress.com/?p=407 ]]> Only some days left for FOSDEM 2012; which this [1] year is organized in Brussels (Belgium).

For anyone interested, I’ll be giving a talk about LTE and ModemManager in the Telephony devroom (room H.2213), in the best time slot possible: Sunday 5th at 09:00 am. If you wake up that early just to attend the talk, you’ll get cookies for free!! [2].

Some GNU hackers will also attend the conference, but this year there won’t be a GNU devroom. If you want to suggest a place for dinner on Friday or Saturday, please do so in the ghm-discuss mailing list.

Cheers and see you there!



[1] (and every)
[2] no, this is not true


Filed under: GNU Planet, Lanedo Planet, Meetings, Planets Tagged: FOSDEM, LTE, ModemManager, NetworkManager ]]> http://sigquit.wordpress.com/2012/01/30/fosdem-2012/feed/ 0 drehbahn I'm going to FOSDEM, the Free and Open Source Software Developers' European Meeting http://sigquit.wordpress.com/2011/11/04/fscons-2011-and-gnu-get-together/ http://sigquit.wordpress.com/2011/11/04/fscons-2011-and-gnu-get-together/#comments Fri, 04 Nov 2011 13:08:30 +0000 aleksander http://sigquit.wordpress.com/?p=402 ]]> I’ll be attending FSCONS 2011 in Göteborg (Sweden) next week (11/11/11), which also holds a GNU get-together, with lots of usual suspects.

Carlos Garnacho, another Lanedian, will be giving a talk about Theming GTK+ applications with CSS, which you shouldn’t miss.

So, if you are interested in developing custom GTK+, LibreOffice, NetworkManager, ModemManager or Tracker features; or any other services provided by Lanedo GmbH, just email me and we’ll be able to talk in Göteborg.

See you there!


Filed under: GNU Planet, Lanedo Planet, Meetings, Planets Tagged: fscons, ghm, gnu ]]> http://sigquit.wordpress.com/2011/11/04/fscons-2011-and-gnu-get-together/feed/ 1 drehbahn http://sigquit.wordpress.com/2011/07/21/unaccenting-words-or-at-least-trying-to/ http://sigquit.wordpress.com/2011/07/21/unaccenting-words-or-at-least-trying-to/#comments Thu, 21 Jul 2011 14:57:50 +0000 aleksander http://sigquit.wordpress.com/?p=376 ]]> So today I found that Tracker in MeeGo packaging was still depending on libunac, while it shouldn’t. And that has reminded me that I had a blog post still unfinished about why and how we removed the libunac dependency in Tracker… so here it goes

One of the features supported in Tracker is doing FTS searches for words without considering ‘accents’. Of course, we’re not talking about accent as in the specific pronunciation of words relative to a location or nation. Our ‘unaccenting’ mechanism, as we call it, refers to the process of removing combining diacritical marks from characters, so that users can look for words with or without these marks. Therefore, this ‘unaccenting’ applies not only to diacritics in Latin alphabets, but also to other alphabets like Arabic, Greek, Hebrew or Korean which also have special combining diacritical marks.

In the previous 0.8 stable series of Tracker, the unaccenting mechanism was completely done by the ‘unac’ library. We were not really convinced that unac was a good option in our case, as it involved extra conversions from UTF-8 to UTF-16 and back, and measurements showed that it was one of the most time consuming steps during FTS parsing. In order to improve the situation, and as we already did ourselves some Unicode normalization work before passing the work to unac, we ended up writing our own unaccenting mechanism in Tracker for 0.10.

The method is applied to all our three Unicode-support backends (GNU libunistring, ICU and GLib), and roughly involves just two steps:

• Apply a compatibility decomposition to the word (NFKD normalization).
• Remove all combining diacritical marks, this is, all Unicode points within the following ranges:
  • Basic range: [U+0300,U+036F]
  • Supplement: [U+1DC0,U+1DFF]
  • For Symbols: [U+20D0,U+20FF]
  • Half marks: [U+FE20,U+FE2F]

Instead of NFKD, NFD decomposition can also be used in the method, but as the main purpose of the unaccenting is a Full Text Search in Tracker, compatibility of Unicode points is also a desired feature which we could get in the same step.

Looking at an example may explain it easier. Consider the French word “école”, which has a diacritic on top of the first ‘e’ character. This accented ‘e’ character can be encoded in UTF-8 in either a composed or decomposed way:

• (NFC, composed) [0xC3 0xA9] 0×63 0x6F 0x6C 0×65
• (NFD, decomposed) 0×65 [0xCC 0x81] 0×63 0x6F 0x6C 0×65

The UTF-8 encoding of the composed way (NFC or NFKC) will (probably) always need less bytes than the decomposed (NFD or NFKD) counterpart. This is because the accented ‘e’ character will be represented in composed way as a single Unicode point: ‘é’ U+00E9 (UTF-8: [0xC3 0xA9]). In the decomposed way, the same accented ‘e’ character is represented as a base character ‘e’ U+0065 (UTF-8: 0×65) plus a combining mark ‘ ́ ‘ U+0301 (UTF-8: [0xCC 0x81]).

For either of the previous two representations of ‘école’, the removal of combining diacritical marks is as we have already described:

• First, get the word NFKD-normalized (or NFD if point compatibility is not needed):
  • (NFC) [0xC3 0xA9] 0×63 0x6F 0x6C 0×65 —>
    (NFKD) 0×65 [0xCC 0x81] 0×63 0x6F 0x6C 0×65
  • (NFD) 0×65 [0xCC 0x81] 0×63 0x6F 0x6C 0×65 —>
    (NFKD) 0×65 [0xCC 0x81] 0×63 0x6F 0x6C 0×65
• Once we have the word decomposed, we can now just walk each unicode point found in the string, and remove those which end up falling into one of the ranges applicable to diacritics. In this case, only the accent on top of the ‘e’ character is found and removed: U+0301 (UTF-8: [0xCC 0x81]):
  • (NFKD) 0×65 [0xCC 0x81] 0×63 0x6F 0x6C 0×65 —>
    (unaccented) 0×65 0×63 0x6F 0x6C 0×65

This new method not only worked perfectly in all the test cases we could think of, it was even much faster than using the unac library (up to 73% faster in the best case, and same speed in more complex cases).


Filed under: Development, GNU Planet, Lanedo Planet, Planets Tagged: diacritics, normalization, tracker, unaccenting, unicode ]]> http://sigquit.wordpress.com/2011/07/21/unaccenting-words-or-at-least-trying-to/feed/ 0 drehbahn http://sigquit.wordpress.com/2011/07/14/modemmanager-now-with-iridium-satellite-network-support/ http://sigquit.wordpress.com/2011/07/14/modemmanager-now-with-iridium-satellite-network-support/#comments Thu, 14 Jul 2011 11:01:47 +0000 aleksander http://sigquit.wordpress.com/?p=370 ]]> ModemManager and the Iridium satellite network

I recently sent a new ‘iridium’ plugin for review upstream, this time for Iridium modems. The plugin was developed using a Iridium 9522B Satellite Transceiver modem connected through RS232, properly handled by ModemManager’s plugin system thanks to the extended RS232 support available in git master. The ‘iridium’ plugin handles these modems as any other GSM modem, even if it has nothing to do with GSM technologies.

Iridium is a constellation of 66 active (plus spares) LEO satellites orbiting at an altitude of 781 km, which gives phone and network coverage to every point in Earth. It was initially thought to be a constellation of 77 satellites, therefore named ‘Iridium’ after the chemical element with atomic number 77. The name didn’t change to ‘Dysprosium‘ when it was redesigned to maintain only 66 active satellites, no wonder why.

Even if the Iridium modems expose a GSM-modem like AT command set, several special things needed to be considered. For example, IP address setup via PPP needed more than the 20s hardcoded in NetworkManager, due to the extreme latency of the satellite network. Therefore, NM was also updated to allow ModemManager plugins to specify a specific ‘IpTimeout’ value.

See my email to the NM mailing list for further information on how to use ModemManager with Iridium support.

Ammonit Measurement GmbH sponsoring some hardware for ModemManager development

In Lanedo we have worked with Ammonit Measurement GmbH to help them with the improvement of ModemManager to handle Wavecom, Cinterion and Iridium modems. The guys at Ammonit were kind enough to sponsor some modems, so that I can spend my free time in developing and improving ModemManager, as well as in testing the modems before stable releases (Dan will probably be happy for that):

• Sierra Wireless Fastrack Xtend FXT009 (GPRS modem, USB, handled by the ‘wavecom’ plugin)
• Cinterion TC63i (GPRS modem, RS232, handled by the ‘cinterion’ plugin)

So, thanks Ammonit!


Filed under: Development, GNU Planet, Lanedo Planet, Planets Tagged: gnu/linux, iridium, ModemManager, network config, NetworkManager ]]> http://sigquit.wordpress.com/2011/07/14/modemmanager-now-with-iridium-satellite-network-support/feed/ 0 drehbahn http://sigquit.wordpress.com/2011/06/02/gnu-pdf-meego-conference-in-san-francisco-new-cinterion-plugin-for-modemmanager/ http://sigquit.wordpress.com/2011/06/02/gnu-pdf-meego-conference-in-san-francisco-new-cinterion-plugin-for-modemmanager/#comments Thu, 02 Jun 2011 14:09:55 +0000 aleksander http://sigquit.wordpress.com/?p=360 ]]> So, May has ended up being a very very busy month.

GNU PDF
After more than 2 months and tons of hours spent in trying not to break the thing (and fixing it when I did break it), I finally finished refactoring the API of the Streams module in GNU PDF in order to use the new error reporting methods. Jose is still reviewing the branch with the changes, so meanwhile I started refactoring the API of the Filesystem module. The Filesystem module is supposed to be just a small layer of abstraction on top of different filesystem backends, but not even the disk backend is fully implemented yet, with some basic pieces still missing. So as part of the API rework, I’ll try to include all missing bits in both the disk and http filesystem backends. Luckily, we got quite a lot of new people coming around the mailing list and providing patches and useful comments for these tasks, so it should be just a matter of time.

ModemManager
Another month hacking ModemManager, working on a new Cinterion plugin. After several changes in the generic code base of the daemon, plugins can now also implement specific features for RS232 modems. The new Cinterion plugin is not available in git master yet, so if you want to give it a try with Cinterion/Siemens USB or RS232 modems, get the following git repo: git://gitorious.org/lanedo/modemmanager.git and checkout the ‘plugin-cinterion’ branch from there.

MeeGo Conference 2011
Lanedo GmbH was one of the sponsors of the MeeGo Conference 2011 in San Francisco, so I had the opportunity to visit the US(of)A again. And I was not the only Spanish guy around: Luis de Bethencourt (Collabora), Iago del Toral (Igalia) and Quim Gil (Nokia) where also in the conference. With Nokia focusing on “that Harmattan thing” as some call it, Intel seems to be the one pushing MeeGo forward (even if not all decisions taken are shared by everyone). It is nice to see that the world didn’t end neither on February 11th (Elopocalypse) nor on May 21st (The Judgment Day, which now seems postponed until October)

Oh, I also turned 30 this past month… I keep on trying to forget it.


Filed under: Development, GNU Planet, Lanedo Planet, Meetings, Planets Tagged: gnu pdf, MeeGo, ModemManager ]]> http://sigquit.wordpress.com/2011/06/02/gnu-pdf-meego-conference-in-san-francisco-new-cinterion-plugin-for-modemmanager/feed/ 0 drehbahn http://sigquit.wordpress.com/2011/05/05/modemmanager-is-fun/ http://sigquit.wordpress.com/2011/05/05/modemmanager-is-fun/#comments Thu, 05 May 2011 15:56:39 +0000 aleksander http://sigquit.wordpress.com/?p=355 ]]> These last weeks I’ve been out of my usual Tracker work, and have been hacking on NetworkManager/ModemManager so that they can work properly with Sierra Wireless Airlink Fastrack Xtend modems.

Ended up writing a new wavecom plugin for this purpose (Wavecom was bought by Sierra Wireless in 2009), which Dan already merged in the master branch of ModemManager.

The changes in the new wavecom plugin with respect to the generic GSM plugin are:

1. AT+CPIN? replies are not ended with OK. A custom regex match was added to support CPIN? replies without OK (also had to hack the generic MM code to handle plugin-provided regular expressions).
2. Disabled default power-up comand, AT+CFUN=1. This command does a full software reset in the device, including the USB stack, so the connection is closed. No additional command seems to be needed, as the modem wakes up by default in CFUN=1 (full functionality) mode. Anyway, an additional check was added during initialization so that this mode is ensured.
3. Enabled RTS/CTS instead of XOFF/XON flow control.
4. Implemented access technology retrieval using AT+WGPRS=9,2 to query network capabilities
5. Ensure the modem uses the highest possible mobile class. These modems can be configured to use different mobile classes. For each kind of modem, the best mobile class is the highest one available, in the following order:
   • Class A (3G only mode)
   • Class B (PS or CS, GPRS/EDGE or GSM)
   • Class CG (PS only, GPRS/EDGE)
   • Class CC (CS only, GSM)
6. Implemented setting and getting allowed mode, for both 2G and 3G based modems (using AT+WWSM command in the 3G case).
7. Implemented setting and getting frequency bands for 2G modems (with AT+WMBS) and 3G modems (with AT+WUBS).

Still, the plugin could be improved even more. For example, there is no secondary port handling in the current plugin implementation, which means that signal strength value will not be updated while the modem is in connected state. This kind of modems support setting up virtual ports by multiplexing the serial channel (CMUX), but ModemManager doesn’t handle this yet.

If anyone has one of this Wavecom/SierraWireless modems at home, please test it with latest ModemManager and report any errors found.


Filed under: Development, GNU Planet, Lanedo Planet, Planets Tagged: freedesktop, gnome, ModemManager, NetworkManager, sierra-wireless, wavecom ]]> http://sigquit.wordpress.com/2011/05/05/modemmanager-is-fun/feed/ 2 drehbahn