This is a translation of my post on measuring temperature with linux, written in German.

The Idea

There are several possibilities to measure temperatures with your computer. 1-Wire sensors like the DS18S20 offer a simple and affordable solution, as it digitalizes the temperature directly inside the sensor and offers an easy interface to query the result. Hence there is no need for analog circuitry or calibration. A comprehensive article on how to wire the sensors to the computer's serial port can be found here. Then there also is the datasheet of the manufacturer as well.

Soldering up

A couple of weeks ago I soldered together a bunch of electronic parts and now I can use my computer to measure room and outside temperatures. For detailed schematics I referred to the aforementioned article.

Part List

  • Any amount of sesors DS18S20 (exactly this part!)
  • One diode 1N5817 per sensor (optional to reduce glitches)
  • Two 1N5818 Schottky diodes (also known as hot carrier diodes)
  • One 1N5234 6.3 Volt zener diode
  • One 1N5228 3.9 Volt zener diode
  • One 1.5 kΩ resistor

Multiple sensors can be hooked up in parallel and 3.5mm stereo jacks are a good option for that. When connecting a larger number of sensors the parasitical power supply will be insufficient and an active power source will be needed. For this purpose, the third pin of the stereo jacks will come handy.

To reduce glitches, you also can solder a 1N5817 diode directly onto the sensor between GND and DATA so that it is open from GND to DATA and blocked from DATA to GND.


Soon I am going to post a tutorial on how to use Metricfire to plot the measured temperature values into nice graphs.


For starters you can use Digitemp to verify the sensors work correctly. First you have to create a configuration file by running

pimp@eekkater:~$ digitemp_DS9097 -i -s /dev/ttyS0
DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane
GNU Public License v2.0 -
Turning off all DS2409 Couplers
Searching the 1-Wire LAN
10AC010202080029 : DS1820/DS18S20/DS1920 Temperature Sensor
1032D4010208008F : DS1820/DS18S20/DS1920 Temperature Sensor
ROM #0 : 10AC010202080029
ROM #1 : 1032D4010208008F
Wrote .digitemprc

This will add all sensors to the configuration file for future calls. Afterwards you can query all sensors at once with digitemp_DS9097 -a.

pimp@eekkater:~$ digitemp_DS9097 -a
DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane
GNU Public License v2.0 -
Apr 10 00:43:59 Sensor 0 C: 11.94 F: 53.49
Apr 10 00:44:00 Sensor 1 C: 21.88 F: 71.38

Der Plan

Um mit einem PC Temperaturen zu messen gibt es mehrere Möglichkeiten. Eine relativ einfache sind 1-Wire Sensoren wie der DS18S20, die die Temperatur bereits im Sensor digitalisieren und die sich über eine einfache Schnittstelle ausgelesen lassen. Somit entfällt eine analoge Schaltung zur Auswertung und eine lästige Kalibrierung. Eine gute Anleitung, wie man diese Sensoren betreibt, gibt es zum Beispiel hier. Außerdem gibt es natürlich das Datenblatt des Herstellers.

Das Gelöt

Vor ein paar Wochen habe ich einen Sensor mit ein paar anderen Bauteilen zusammengelötet und jetzt kann mein PC damit die Raumtemperatur messen.


  • Eine beliebige Anzahl Temperatursensoren DS18S20 (genau dieser!)
  • Pro Sensor eine 1N5817 Diode (optional, um Glitches zu reduzieren)
  • Zwei 1N5818 Schottky-Dioden
  • Eine 6,3 Volt Zener-Diode 1N5234
  • Eine 3,9 Volz Zener-Diode 1N5228
  • Ein 1,5 kΩ Widerstand

Mehrere Sensoren kann man parallel anschließen und dafür eignen sich 3,5mm Klinkenstecker ganz gut, für die es passende Kabel und Verteiler zu kaufen gibt. Ab einer größeren Zahl von Sensoren kann eine zusätzliche Stromversorgung nötig werden, da die parasitäre Versorgung über die Serialschnittstelle nur für wenige Sensoren ausreicht. Dafür steht dann der dritte Leiter der 3,5mm Stereokabel verfügbar.

Um Glitches zu reduzieren, kann man direkt am Sensor eine 1N5817 Diode zwischen GND und DATA löten, so dass sie von GND nach DATA offen ist und von DATA nach GND sperrt.


Demnächst gibt es eine Anleitung, wie man die Messwerte mit Metricfire möglichst einfach zu schönen Graphen stricken kann.


Fürs erste hilft Digitemp weiter um zu überprüfen, dass die Sensoren funktionieren. Zunächst muss eine Konfigurationsdatei erstellt werden:

pimp@eekkater:~$ digitemp_DS9097 -i -s /dev/ttyS0
DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane
GNU Public License v2.0 -
Turning off all DS2409 Couplers
Searching the 1-Wire LAN
10AC010202080029 : DS1820/DS18S20/DS1920 Temperature Sensor
1032D4010208008F : DS1820/DS18S20/DS1920 Temperature Sensor
ROM #0 : 10AC010202080029
ROM #1 : 1032D4010208008F
Wrote .digitemprc

Dabei werden alle gefundenen Sensoren in die Konfigurationsdatei eingetragen. Anschließend kann man mit dem Befehl digitemp_DS9097 -a alle Sensoren gleichzeitig auslesen.

pimp@eekkater:~$ digitemp_DS9097 -a
DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane
GNU Public License v2.0 -
Apr 10 00:43:59 Sensor 0 C: 11.94 F: 53.49
Apr 10 00:44:00 Sensor 1 C: 21.88 F: 71.38

To get free (no ads) SSH access to an unrooted Android device you can use DroidSSHd. First install the latest APK from here. Then open the DroidSSHd app on your device and enter a password in Preferences, Service and Authentication, Password. After this, hit Start and you should be able to connect to the IP and Port displayed.

Setting up keybased logins

At this point, only SSH will work. SFTP or SCP are not yet working and to copy your SSH key, we will have to live with SSH alone. Assuming your public key file is located at .ssh/, run on your desktop computer:

cat .ssh/ | ssh -p <PORT> <IP> "cat - > /mnt/sdcard/.key"

The file will not be visible in the Android file manager, but you will be able to select it in the Public Key preference in DroidSSHd. After selecting the key, you should be able to login without a password.

SFTP - Mount the Device's Filesystem

In order to mount the device via Fuse/SSH you have to get SFTP working. The DroidSSHd app currently does not provide the required sftp-server binary. However you can download it here (local copy, MD5). Next, transfer the binary to the device by running (again on the desktop):

cat /<PATH-TO>/sftp-server | ssh -p <PORT> <IP> "cat - > /data/data/"

You will most likely also have to make the file executable, so SSH to your Android device and run

android@android:/mnt/sdcard $ chmod 755 /data/data/

Now you should be able to mount the device from your desktop like so:

$ sshfs -p <PORT> <IP>:/ <MOUNTPOINT>

In my case, this was:

sshfs -p 9922 tab.ea:/ fuse/ssh/

You should now be able to copy files from and this location as normal. Enjoy.

How can I copy from files from one Linux (or generally, any Unix based OS) device to another? Assuming both have some kind of network connection, I usually go and install my SSH key on the target device and then simply run scp or rsync, the latter being especially useful if I need to update the remote file tree. If for some reason there was no SSH, I might resort to FTP, SFTP even, SMB, NFS.

The only option Android leaves - at least if you don't want to void the warranty by rooting the device - is this: Connect the device with a cable (remember this being on the same network) and use the worst protocol you can think of to copy files to the device. Even in the latest Ubuntu the version of the library needed for that is to old, so you will have to painfully upgrade it. Rage ensued!!

I'm not even sure whether Google or Samsung, which manufactured the device in question, are to blame for this. One of them however broke the whole concept of networked devices just to force everyone to either rebreak the jailed concept alltogether or ressort to a crippled, restricted Microsoft developed protocol like MTP. What where they thinking a user would need to copy files?

Dear Google, please fix that. Give the users some way to copy files to their device from native Linux environments. Create an app to run an SFTP server, be it jailed to parts of the file system and let me copy files over there as I usually do. I will now have to head to the Market and look for some third party app to copy files. The heck!

Today I tried to copy files to a Samsung Galaxy Tab 10.1. After figuring out, that it will only talk MTP via the USB port, I installed the mtp-tools package and happily ran mtp-detect in a shell.

pimp@eekkater:~$ mtp-detect 
libmtp version: 1.1.0

Listing raw device(s)
Device 0 (VID=04e8 and PID=6860) is a Samsung GT-P7510/Galaxy Tab 10.1.
   Found 1 device(s):
   Samsung: GT-P7510/Galaxy Tab 10.1 (04e8:6860) @ bus 1, dev 17
Attempting to connect device(s)
PTP_ERROR_IO: failed to open session, trying again after resetting USB interface
LIBMTP libusb: Attempt to reset device
inep: usb_get_endpoint_status(): No such device
outep: usb_get_endpoint_status(): No such device
usb_clear_halt() on IN endpoint: No such device
usb_clear_halt() on OUT endpoint: No such device
usb_clear_halt() on INTERRUPT endpoint: No such device
ignoring usb_claim_interface = -9ignoring usb_claim_interface = -22LIBMTP PANIC: failed to open session on second attempt
Unable to open raw device 0

Truly, the best part is the last line. However, nothing was OKok and some ducking later I figured I had to upgrade libmtp to the latest version by hand. As I'd like future Ubuntu package upgrades not to break my upgraded version and hoping that the maintainers will sooner or later catch up, I decided to build the packages with the new source. Thanks to the package using some modern design paradigms, there was little effort needed to get the whole thing going. Most of the basic steps are similar for other packages and are – among others – documented in the Debian New Maintainer Guide in the chapter on new upstream releases.

The Upgrade Process

First you have to install the build requirements by running:

sudo aptitude build-depends libmtp

Then you can download the old version's source package from the Ubuntu repositories:

apt-get source libmtp

This will automatically download and extract everything for you, so you theoretically could rebuild the old version without any further steps.

Now to the actual upgrade. The libmtp package comes with a watch file, which contains the URL to look at for new versions. Thus you only need to run uscan from inside the package directory:

cd libmtp-1.1.0/; uscan

which – if successful – will output:

libmtp: Newer version (1.1.2) available on remote site:
  (local version is 1.1.0)
libmtp: Successfully downloaded updated package libmtp-1.1.2.tar.gz
    and symlinked libmtp_1.1.2.orig.tar.gz to it

Hooray! That's the version we want. Next you need to unpack the new source and copy all Debian build specific stuff over there. This action being quite common among the build processes, there's a helper for that as well. Run

uupdate -v 1.1.2 ../libmtp_1.1.2.orig.tar.gz

which – if successful – will output:

New Release will be 1.1.2-0ubuntu1.
-- Untarring the new sourcecode archive ../libmtp_1.1.2.orig.tar.gz
Unpacking the debian/ directory from version 1.1.0-3ubuntu1 worked fine.
Remember: Your current directory is the OLD sourcearchive!
Do a "cd ../libmtp-1.1.2" to see the new package

Do as it says to change to the new package.

cd ../libtmp-1.1.2

There we will apply patches to the source tree, which are included in Ubuntus version of the package and adapt it's behaviour to the specifics of Ubuntu. As most of the patches failed, I figured I'd only keep the one which worked and looked like it did more than add support for some devices. The file debian/patches/series contains all patches that will be applied. Edit it and remove all patches except for 1002-udev_rules.patch.

echo 1002-udev_rules.patch > debian/patches/series

Now we will apply all (that single) patches to the sources by running:

while dquilt push; do dquilt refresh; done

Next you have to update the changelog file to reflect the new version of the package. There is a helper for that as well which will fill out almost everything you need. Run:


and add any comment as you wish, for example "Fix libmtp support for the Galaxy Tab". There are some rules, which you would have to follow if you were to distribute the package through the official Debian/Ubuntu channels, but let's just assume you won't.

One more thing to do before you can start the build. One filename in the upstream release is different, so you will have to run

sed -i -e 's/39/69/' debian/libmtp-common.install

and point the build system to the right path. After that you're ready. Fire up


and watch the whole thing build – it will output quite some lines during the process. After it has finished, you should have (among others) the following files

$ ls ../*deb

in the parent directory. Go ahead and upgrade your installed packages by running [*]

sudo dpkg -i ../libmtp9_1.1.2-0ubuntu1_amd64.deb ../libmtp-common_1.1.2-0ubuntu1_all.deb ../libmtp-runtime_1.1.2-0ubuntu1_amd64.deb ../mtp-tools_1.1.2-0ubuntu1_amd64.deb

Run mtp-detect again and it will output a long list of specs for your device. Hooray!

[*] Warning: Your file names may differ if you're not on a 64bit machine.

Automatically Dimming the Backlight on Battery

Since upgrading my Thinkpad to the latest Xubuntu I have noticed that after 10 seconds of inactivity the display backlight automatically dimms down, which makes reading text for more than a couple of seconds pretty annoying. The question had already been asked on but the answer was gnome specific and I could not find the specified dialog on Xubuntu, nor could I find the options in gconf-editor.

Ruling Out the Causes

As changing the auto-dimming level and timeout in xfce4-power-manager-settings did not fix it, I consecutively killed the xfce4-power-manager process, xscreensaver and upowerd, all without any success

gnome-settings-manager it is

Finally I stumbled over this bug report where a gsettings command is given, that will change the timeout. A quick

gsettings set org.gnome.settings-daemon.plugins.power idle-dim-time <seconds>

will fix it.

gconf-editor - dconf-editor

After that, I also found a gui to edit the gsettings database called dconf-editor, which is found in the dconf-tools package. Inside, browse to org.gnome.settings-daemon.plugins.power and you will find more settings and even get to disable the power plugin alltogether.

The following steps are needed to use a brother scanner via network on Ubuntu 9.10:
  1. Go to the Brother driver page and download the right .deb file (32/64bit).
  2. Install the .deb file. If you just click it, gdebi will do that for you.
  3. Install gscan2pdf, a great GTK+ tool for scanning and exporting the scanned pages to various formats.
  4. Configure the scanner to be on the network. Depending on the installed printer model, the used tool will be called brsaneconfig, brscaneconfig2 or brscaneconfig3. For the MFC-7820N the command is: brsaneconfig2 -a name="Lars MFC" model="MFC-7820N" ip=
    • The IP address has to be numerical, no hostname is allowed, DNS is not used.
    • The model is checked as well. If brsaneconfig complains, you better look it up on the Brother page.
    • Of course you are allowed to name your scanner whatever name you like.
There you go. has a wiki page with detailed information on the subject (German).

Gerade hatte ich folgende Symptome: Beim verschieben eines Fensters wurde der Bildschirm schwarz. Immer, wenn ich ein Fenster, egal wie groß, hin- und herschieben wollte - zack - Bildschirm aus. Natürlich hab ich sofort an den blöden ATI Treiber gedacht, konnte aber nichts dazu finden. Also hab ich mich mal aus- und wieder eingeloggt. Danach war das Problem weg. Dafür fing das Bild im Monitor an zu zittern, als hätte er Angst. Am Anfang zuckte es nur alle paar Sekunden. Nach 1-2 Minuten war es dann ein beständiges Zappeln. Und was war's am Ende? Der DVI-Stecker war locker. Dann passiert sowas. Komischer Kram.
Update 08. März 2009
Es war wohl doch nicht der DVI-Stecker. Gestern ist es nämlich schon wieder passiert. Diesmal hab ich mit xrandr bissle am Modus rumgefingert, und plötzlich ging alles wieder. Mal sehen, wie lange.

Oh how I longed for that feature: Whenever I log into XFCE, I want my ssh key to be automatically added to my authentication agent. Although it took some time, I finally puzzled together all the pieces to make it work. So here it is. 3 simple steps to get auto-adding to work in Xubuntu karmic koala:
  1. Enable "start gnome environment" in XFCE settings
  2. Comment out the line "use-ssh-agent" in /etc/X11/Xsession.options. This prevents the ssh-agent from starting. Instead gnome-keyring-daemon's internal agent will be used. However ssh-agent would overwrite it's socket variable, so we disable it here.
  3. Place the following into your ~/.xprofile: if [ -n "$GNOME_KEYRING_PID" ]; then eval `gnome-keyring-daemon --start` export SSH_AUTH_SOCK fi
There you go. If it does not work after a re-login, leave a comment below. Further information regarding the GNOME startup process and the way gnome-keyring-daemon gets started (it's actually started twice, huh!) can be found in this bug report.

16. April 2010: Update for Lucid Lynx

Apparently my fix from above prevents things from working Lucid. Therefore, if you have problems, unset everything and it should work. Nice. It seems to be totally broken in lucid. After wasting already to much time for this, I filed a bug report about it, we'll see what happens:

Jetzt hab ich also Sub-Pixel Hinting angeschaltet und zumindest auf meinem Samsung 193P sieht es sehr schick aus. Nach etwas Rumprobieren und genauem Hinschauen sieht man, dass der Monitor RGB-Pixel hat. Für Firefox 3.5 braucht es unter Xubuntu Karmic folgenden Hack: sudo rm /etc/fonts/conf.d/10-hinting-slight.conf sudo rm /etc/fonts/conf.d/10-no-sub-pixel.conf sudo ln -s /etc/fonts/conf.available/10-hinting-medium.conf /etc/fonts/conf.d/. sudo ln -s /etc/fonts/conf.available/10-sub-pixel-rgb.conf /etc/fonts/conf.d/. sudo dpkg-reconfigure fontconfig Quelle:

Next Page »