Michal Čihař - Blog Archives for English

Nokia cables

What does cryptic shortcut for different cables for different Nokia phones mean? This was always a bit confusing to me. Now I finally found some document which writes quite clearly, what all they do. Unfortunately for most readers of this blog, it is only in Czech language - Ovládání mobilního telefonu jednočipovým mikroprocesorem. However here is quick summary if somebody is interested:

MBUS

Single wire (+ ground) connection, usually used for servicing phone, but sometimes also exposes some functionality. Fixed baud rate at 9600. DTR and RTS usually used as power source, DTR should be low and RTS high.

FBUS

Two wire (+ ground) connection, used for user data. Variable baud rate (but usually 115200). DTR and RTS usually used as power source, DTR should be low and RTS high.

DAU-9 / DLR-3

Cables for both FBUS and MBUS, switching is usually done by toggling RTS or DTR signals (for DAU-9) or special AT command (for DLR-3). DLR-3 also additionally supports AT commands over FBUS lines.

DKU-5

This is basically DLR-3 cable with USB/RS232 converter, so it is first step of getting USB into phones.

DKU-2

This is for recent phones which directly support USB, it contains no logic, just wires for USB.

Gammu test version 1.13.91

I just released new version of Gammu. This is simply bug fixing release, no major new features. Full list of changes:

  • Fixed reading of empty calendar/todo/contacts/notes over OBEX (thanks to Gianni Ceccarelli).
  • Fixed overwriting of Java applications in Nokia phones (thanks to Martin Thierer, bug 382).
  • Fixed compilation with older PostgreSQL libraries.
  • Handle correcly internal phone errors in OBEX module.
  • Fixed crash on invalid config file (Debian bug #444046).
  • Better report errors when using default configuration.
  • Fix several buffer overflows in 6510 (thanks to Tobias Sunderdiek for debugging this).
  • Fixed crash on decoding messages with special numbering plans with long numbers (bug 281).
  • Command nokiaaddfile can now either keep or delete user data on uploading new application (thanks to Martin Thierer, bug 385).

SCons is next-generation build tool?

You can read following text on SCons homepage:

SCons is an Open Source software construction tool—that is, a next-generation build tool. Think of SCons as an improved, cross-platform substitute for the classic Make utility with integrated functionality similar to autoconf/automake and compiler caches such as ccache. In short, SCons is an easier, more reliable and faster way to build software.

Then they list tons of features. But why the hell it does not support DESTDIR like functionality out of the box? While googling for this I found that most projects add the same code to handle this feature that will be used by almost every Linux distribution. I think such feature should be built in into next-generation build tool.

PS: If you're asking what would I use, it is simple - for Python just use distutils, they do what you need, for rest I can recommend CMake.

PS2: I just need to express my disappointment after packaging pyexiv2 which uses scons.

Exiv2 support for Pentax maker notes

As I have Pentax camera, I wanted to be able to extract information from maker notes it stores to EXIF. As only tool which seems to be capable of this is ExifTool and it is a Perl beast which I really don't want to use from Python, I need to add support for it to some existing library.

I found two which could be used - libexif and Exiv2. Because of availability of Python bindings I choose Exiv2. The reason why I also prefer this is upcoming XMP support for which I was looking recently. The only disadvantage I can see is that libexif is more widely used by applications. Why the hell couldn't be just one library doing this?

Anyway if you're interested in Pentax maker note support for Exiv2, you can find it in their bug tracker and it will hopefully appear soon in their svn ;-).

First success with Photo uploader

Today I did really big stress testing of Photo uploader - I needed to upload 400 photos (total size somewhere near 600 MiB). And it worked without problems! I could not imagine that I would have to upload so much files using web forms or some damn slow Windows application.

Also since last announcement uploader development went on. It now supports 4 services (all in Czechia for now), I added some documentation and man page. Also version 0.1 has been released yesterday (but it does not yet contain mentioned updates), with plan to release 0.2 somewhere next week.

And as I got quite a lot of requests for GUI - I do not plan to write one myself (or at least not soon). So if you want one, please write it. As all hard work is done by phoupl module, it can be easily embedded into some simple image viewer written in Python.

Uploading photos to minilab

I was looking for some easier solution than using web forms, but no minilab seems to support Linux here. Windows applications I tried so far does not seem to work in Wine, so this is also not an option. Only thing that seems to work is Picassa, but it is quite big tool to make just uploading photos and it is anyway some beast using Wine.

So the only option was to write something myself. Using cURL from Python is quite easy so I hacked simple script to upload photos to minilab using PycURL. It currently supports only Droxi, but it might be later extended to support others. The code is also now a bit fragile as it does almost none error checking, but I was able to upload first set of photos to minilab and continue order in browser.

You can download my proof of concept code at Photo uploader page, but don't expect anything clever from it, but it should basically work :-).

XMP support for Python

As I produce quite a lot of photos and want to manage them in some reasonable way, I started to look for some tools which can do commenting/tagging/whatever of taken photos. I really don't want these meta data stored outside picture itself, so most of photo managers currently available are not acceptable. When reading Gnome 2.20, I noticed support for XMP (Extensible Metadata Platform) in eog.

Well I didn't know this standard up to now, but it looks interesting. Especially when open source tools can easily adopt library open sourced by Adobe. I would like to add support for this to Lazygal, but I didn't find any reasonable Python module to work with XMP. There is simple extractor, but nothing what would allow me to easily grab meta data out of file. In fact one solution seems to exist, but it costs almost $300 and is not free software in any way.

Or did I just miss something when using Google and some such Python library exists?

Pentax won

On Friday I finally made the decision - from the two cameras that left in choice, I bought Pentax K10D. And first experiences are quite positive. In fact I didn't find anything really disappointing during first weekend of usage. I only learned, that I should better check manual choices I've made in the past, because changing white balance at interior, going out and taking photos there does not really produce great pictures.

The camera feels really good in my hands and I was able to figure out most settings without reading manual, but I think now it is time to do so :-). Maybe it will help me to get even more out of it, especially in controlling manual modes.

I have to admit that most of photos were left to automatics and I just tried what I can do with it. Combined with trips to Kyoto, Nagoya Castle and Inuyama, it is no wonder that I took almost 1000 photos during weekend.

Thanks to everybody who helped me with their suggestions, it really helped me in the decision!

Funny advertisements

It's sometimes funny what automatically added advertisements can produce. This morning when I complained about lack of Windows developers for Gammu and shared my unwillingness to work on Windows, Microsoft sponsored this email ;-).

On Wed, 12 Sep 2007 09:55:56 +0900
Michal Čihař <michal@cihar.com> wrote:

> I have totally no interest in investing into Windows license and
> finding out how to use totally free MSVC.
[...]
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.