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.






Software

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

Digitemp

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 - http://www.digitemp.com
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 - http://www.digitemp.com
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.

Teileliste

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






Software

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

Digitemp

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 - http://www.digitemp.com
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 - http://www.digitemp.com
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

This article by SethRobertson titled On undoing, fixing, or removing commits in git explains how to fix or rewrite almost anything in Git. It just helped my to remove a sensitive API key from a file throughout the whole history of my repository.

Ealier I already wrote about using the gnome-keyring-daemon to automatically unlock the SSH key when logging into XFCE. The method I described in the latter of my posts had the drawback of launching a complete GNOME session together with all its associated services.

The way the developers of the daemon intended it to work uses DBUS to inject the global variables pointing the various sockets to be used by SSH and GnuPG into the global session environment. However XFCE does not support this injection which currently is one of the magic things happening when launching the GNOME environment at login time.

More information on the current state of the issue can be found in Redhat's Bugzilla in bug 551508. The workaround depicted there is to place the following into your ~/.profile file (or any other file evaluated during session initialization):

# add gnome-keyring-daemon to env
export `gnome-keyring-daemon --start`

In XFCE you can change the screen DPI in the Font tab in the Appearance dialog, which will instantly take effect. If you want to script the change, e.g. when upon connection with a docking station, you can use the following command:

xfconf-query -c xsettings -p /Xft/DPI -s <NEW_DPI>

To display the current DPI, you can just omit the -s <NEW_DPI> part.

Die Kette am Spinning-Rad knackt.

Die Kette am Spinning-Rad knackt nochmal.

Die Kette am Spinning-Rad reißt.

Ich schraube den Kettenschutz ab.

In der Fahrradwerkstatt kaufe ich eine neue Kette.

Ich baue das Schwungrad aus, die Schrauben lösen sich nur schwer.

Eine der Schrauben dreht sich beim Wiedereinbau rund.

Beim Baumarkt will ich eine neue Schraube kaufen.

Scheinbar gibt es neben normalen Schrauben auch noch Karosserieschrauben.

Ich kaufe eine normale Schraube, einen Gewindeschneider plus Einsatz und Schneideöl.

Ich würge ein Gewinde in die Schwungradachse und schraube alles wieder zusammen.

Der halbe Tag ist rum.

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/id_rsa.pub, run on your desktop computer:

cat .ssh/id_rsa.pub | 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/br.com.bott.droidsshd/files/bin/sftp-server"

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/br.com.bott.droidsshd/files/bin/sftp-server

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!

Here is a list of very cool, useful projects enhancing the already great Twitter Bootstrap:

  • Lavish creates a Bootstrap colorscheme (CSS and LESS) out of any image you supply. This link will launch a colorscheme for the website of the JDAV Baden-Württemberg.

  • StyleBootstrap will give you a finer grained control over the color choices. It allows you to format fonts and colors of elements of the Bootstrap layout like the Navbar, the text body, buttons and forms.

  • Boilerstrap combines Bootstrap with lots of useful tools you almost certainly want to have like the HTML5 Boilerplate tweaks, Modernizr loading, javascript compression and other useful things.

  • WrapBootstrap has a list of commercial Bootstrap template with an option to buy one if you like it.

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

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:
  http://qa.debian.org/watch/sf.php/libmtp/libmtp-1.1.2.tar.gz
  (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:

dch

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

debuild

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
../libmtp9_1.1.2-0ubuntu1_amd64.deb
../libmtp-common_1.1.2-0ubuntu1_all.deb
../libmtp-dbg_1.1.2-0ubuntu1_amd64.deb
../libmtp-dev_1.1.2-0ubuntu1_all.deb
../libmtp-doc_1.1.2-0ubuntu1_all.deb
../libmtp-runtime_1.1.2-0ubuntu1_amd64.deb
../mtp-tools_1.1.2-0ubuntu1_amd64.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.

Next Page »