Für Code for Germany habe ich eine Karte erstellt, auf der man sehen kann, von wo auf der Welt schnell ein Bahnhof erreicht werden kann – und wie sich die Situation ändert, sobald man im Rollstuhl sitzt.

Die Daten der Bahnhöfe stammen aus der API von OpenStreetmap. Wenn keine Informationen über Barrieren verfügbar sind, werden sie einfach grau dargestellt. Alle anderen sind blau. Aber sobald man oben rechts auf den Rollstuhl klickt, verschwinden viele Bahnhöfe wieder. Das sind die, zu denen nun kein Zugang mehr besteht. In Berlin sind nur kleinere U-Bahn-Linien betroffen. Ganz anders sieht die Situation in Paris aus: Es können nur noch ein paar Seilbahnen oder der Fernverkehr genutzt werden.

Zur Karte

Der Quellcode auf Github steht unter der MIT-Lizenz.

In meiner Netzwerkfestplatte werkelt ein kleiner ARM-Prozessor Feroceon 88FR131 unter Debian. Er ist schnell genug für eine Shell und eine kleine Web-Oberfläche, aber zu langsam für moderne Crypto über große Datenmengen. Der SSH-Server bietet dem Client eine große Auswahl Algorithmen zur Kommunikation an und verständigt sich dann meist auf den zuverlässigsten. Bei mir blieben noch 5,6MB/s übrig, was mir definitiv zu langsam ist.

Also erstellte ich eine 400MB große Testdatei und kopierte sie mit verschiedenen Ciphern immer wieder übers Netzwerk.

$ scp -c aes256-cbc testfile 192.168.1.20:~
testfile       100%  401MB   5.1MB/s   01:19

Cipher	Datendurchsatz
3des-cbc	2.5MB/s
aes128-ctr	6.1MB/s
aes192-ctr	5.4MB/s
aes256-ctr	5.0MB/s
arcfour128	11.1MB/s
blowfish-cbc	8.9MB/s
aes128-cbc	6.0MB/s
aes192-cbc	5.6MB/s
aes256-cbc	5.1MB/s
arcfour	11.1MB/s
arcfour256	11.1MB/s
cast128-cbc	8.4MB/s

Mehr als 11.1MB/s schafft das 100Mbit-Ethernet nicht. Da auch viele kleine Dateien schnell kopiert werden müssen, habe ich ein Verzeichnis mit 282 JPG-Bildern mit insgesamt 38,6MB angelegt. Beim Kopieren wurde wieder die Zeit gemessen. Mit dem voreingestellten Algorithmus dauerte es 7,4 Sekunden.

$ START=$(date +%s.%N)
  && scp -c blowfish-cbc -q test/* 192.168.1.20:~/test
  && END=$(date +%s.%N)
  && DIFF=$(echo "$END - $START" | bc)
  && echo $DIFF
5.343504576

Cipher	282 Dateien 40MB	2256 Dateien 300MB
aes128-ctr	7.4s	64s
arcfour128	4.4s	39s
blowfish-cbc	5.3s	47s
arcfour	4.4s	40s
arcfour256	4.8s	40s
cast128-cbc	5.6s	46s

Es sieht also so aus, als würden Blowfish, Arcfour und Cast das Rennen machen. Bei Arcfour sollte man arcfour256 bevorzugen. Dagegen scheint cast128 für nichts gut zu sein. Der Standard für schnelles SSH ist wohl Blowfish.

Um den Server auf Arcfour zu beschränken habe ich in der /etc/ssh/sshd_config folgende Zeile angehängt:

Ciphers arcfour256

Nach einem Neustart des SSH-Servers beträgt der Datendurchsatz statt 5.6MB/s nun 9.7MB/s. Mein Client-Notebook ist dabei nur zu wenigen Prozent ausgelastet, der Server zu 100%.

Das Einbinden der Netzwerkfestplatte geschieht übrigens nicht über Gnomes langsames und anfälliges gvfs, sondern auf Dateisystem-Ebene mit sshfs.

Die Geschichte des Telegrafie-Unterrichts ist so lang wie die des Morse-Codes. Im 19. Jahrhundert prägten sich die Telegrafisten die Bilder für jedes einzelne Morsezeichen ein. „·−“ hieß A, „'−···“ war ein B. Die Zeichen wurden auf eine schmale Rolle Papier gedruckt. Schnell wurde klar, dass der Melodie des Druckers zu hören viel einfacher war, als Punkte und Striche abzuzählen. Auf das Papier wurde bald verzichtet. Dafür konnte die Geschwindigkeit erhöht werden, so dass Dits und Dahs verschwammen. Die Telegrafisten achteten nur noch auf die Melodie der Zeichen oder ganzen Wörter. Morsen ist halt eine Sprache, die man zwar nicht sprechen, aber nur durch Hören lernen kann.

Es dauerte Jahrzehnte, bis Wissenschafter diese Erkenntnisse auch für die Lehre vorschlugen. Der Psychologe Ludwig Koch empfahl schließlich 1936, Morsezeichen von Anfang an mit hoher Geschwindigkeit zu lernen. Statt zu zählen kommt es auf den Klang eines Zeichens an, und den hört man nur, wenn ein Dit, also ein Punkt, weniger als 50ms dauert. Nach einigen Stunden Übung lassen sich so pro Minute bereits 25 Wörter aufnehmen, das entspricht etwa 150 Zeichen.

Zum Üben brauchte man immer seltener einen Kurs zu besuchen, denn es erschienen Schallplatten, Kassetten, CDs und Computer-Programme mit Übungen nach der Koch-Methode. Die letzte große Neuerung war mit LCWO der Online-Morse-Trainer. Man kann sich einfach an den Rechner setzen und sofort anfangen zu üben. Der Rechner kontrolliert die Ergebnisse, erstellt Statistiken und Rangfolgen. Nur eines gab es schon lange in keinem Morse-Kurs mehr: abgedruckte Morsezeichen.

morseSynth

Seit kurzem ist es mit der Web Audio API möglich geworden, Morsezeichen direkt im Browser herzustellen. Man kann in JavaScript die Wellenform, Frequenz, Lautstärke, Anstiegszeiten und sogar Störungen einstellen, die dann auf den Rechnern der Besucher synthetisiert werden. Auch verschiedene Signale gleichzeitig, wie sie bei hohem Andrang oft vorkommen, sind kein Problem. Um die Programmierung zu vereinfachen, habe ich die Bibliothek morseSynth geschrieben. Sie versteht sich mit reinem JavaScript genau so wie jQuery und anderen Frameworks. Im HTML muss nur die Bibliothek eingebunden werden, schon lassen sich Buttons zum Abspielen oder Anhalten auf der Seite verteilen. Das Signal lässt sich mit vielen Parametern einstellen.

Mir fallen einige Anwendungsmöglichkeiten ein. Ein Morsekurs liegt nahe. Man kann aber auch einfach auf einer Amateurfunk-Seite einen „geheimen“ Witz unterbringen oder besondere Bedingungen im Funkverkehr veranschaulichen. Es lassen sich ganze Bücher wiedergeben und dabei nur den Speicherbedarf der reinen Textdateien benötigen. Ich bin gespannt, ob die Bibliothek irgendwo mal genutzt wird.

Dokumentation und Download von morseSynth

Leider zeigen die Android-Browser ihre Konsolen nicht an. Man muss die Entwickler-Werkzeuge auf dem PC über USB nutzen. Unter Ubuntu 13.10 und Android 4.4 geht das so:

Die Pakete android-tools-adb und chromium-browser installieren. Im Android-Gerät unter Einstellungen - Über das Telefon siebenmal auf Build-Nummer tippen, dann erscheint die Nachricht, dass man Entwickler ist. Anschließend in Einstellungen - Entwickleroptionen die Option USB-Debugging aktivieren.

Jetzt das Mobilgerät an den PC stecken. Es sollte ein Hinweis auf USB-Debugging erscheinen. Chromium starten und die Adresse chrome:inspect eingeben. Hier sollte das Phone mit allen geöffneten Webseiten zu sehen sein, selbst wenn Chrome for Android gerade nur im Hintergrund läuft.

Diese Lösung ist so einfach und für mich viel besser als eine Konsole auf dem Android-Gerät. Man kann übrigens auch mit „adb forward tcp:9222 localabstract:chrome_devtools_remote“ eine Webseite unter localhost:9222 einrichten. Darauf kann man auch im Firefox und jedem anderen Browser die Konsole von Chrome for Android bearbeiten. Bei mir funktioniert das allerdings nicht richtig.

Zu einer elektronisch gesteuerten Beleuchtung gehört in der Regel die Messung des verfügbaren Tageslichtes. Ich beschränkte mich beim FS20-System auf die Messung mit einem einzelnen Sensor. Aufwändigere Installationen haben einen pro Himmelsrichtung. Von ELV gibt es für diese Aufgabe den Dämmerungssender FS20 SD. Wie der Regensensor FS20 SR, der Bodenfeuchte-Sensor FS20 BF und viele andere sendet er nur Daten, wenn sich der Zustand ändert, also typischerweise zweimal am Tag. Da FS20 recht unzuverlässig ist, reicht das nicht, um wirklich zu wissen, ob es draußen hell oder dunkel ist. Man könnte ja einen Datensatz verpasst haben. Außerdem muss man die Schwellen am Sensor eingeben, was funktioniert, aber nicht besonders komfortabel ist.

Ich habe den Temperatur-Sensor HMS 100 T zu einem Beleuchtungsstärke-Messgerät umgebaut. Er sendet alle fünf Minuten einen Messwert. Da er nichts empfängt und nicht konfiguriert werden kann, ist der Betrieb sehr einfach. Batterien einlegen und fertig.

Empfangen kann man ihn wie alle HMS-Geräte nicht mit den üblichen Aktoren wie z.B. Dimmern. Eine Zentrale muss die Helligkeit empfangen und auswerten. Bei mir ist es der CUL-Adapter von Busware an einem Rechner (Raspberry Pi oder Atom-PC) mit CUL_FS20 unter node.js.

Der Sensor sendet einen Datensatz, der mit H beginnt. Normalerweise senden die FS20-Sensoren etwas mit F am Anfang, und das erwarten auch die Aktoren. Daten mit H sind Messwerte. So ein Datensatz sieht z.B. so aus:

H1403017104000D

Das H heißt, dass ein Messwert folgt. Die nächsten vier Zeichen sind die Adresse. Sie unterscheiden sich damit von den üblichen FS20-Adressen, die vier Zeichen Hauscode und zwei Zeichen Adresse senden. Dazu kommt, dass der Sensor beim Stromverlust seine Adresse vergisst. Nach dem Batteriewechsel muss sich die Zentrale an eine neue Adresse gewöhnen. Die letzten zwei Zeichen sind die Checksumme. Es bleiben acht Zeichen für Nutzdaten.

H8F97012103001D
H = prefix
 8F97: device address (changes after battery loss)
     0: status bits
      1: 1=on (seems useless)
       21 3: Temperatur
         0 00: Feuchtigkeit
             1D: checksum

Die Status-Bits sind unter anderem 0=OK, 2=leer, 4=replaced, 8=negative Temperatur. Man sieht, dass die Adresse erst 1403 ist und später 8F97. Keine Ahnung, wie man mehrere Sensoren auseinanderhalten soll. Anscheinend muss man bei jedem Batteriewechsel in der Zentrale die neue Adresse eingeben.

Bei der Temperatur ist erst die zweite, dann die dritte und dann die erste Dezimalstelle angegeben, wobei die dritte eine Nachkommastelle ist. Im Beispiel haben wir 32.1°C. Bei der Feuchte ist erst die dritte, dann die erste und dann die zweite Stelle angegeben, wieder mit einer Nachkommastelle.

Weitere Informationen zu den Daten der HMS-Sensoren befinden sich im FHEM-Projekt in der Datei FHEM/12_HMS.pl.

Umbau zum Beleuchtungsstärke-Messgerät

Ich habe einfach den Heißleiter vom Kabel abgeknipst und statt dessen verschiedene feste Widerstände angeschlossen. Die gesendeten Temperaturen schrieb ich als Kiloohm/Gradcelsius-Paare, in folgende Datei „Temperatur über Widerstand“:

47.8,4.5
20.2,12
4.8,22.5
-4.4,33.3
-27.6,99
-33.2,132
-40.4,270

Mit folgendem Gnuplot-Script erhielt ich daraus einen Graphen:

set output './Temperatur über Widerstand.png'
set terminal png size 900,600
set datafile separator ","
set ylabel "R/kΩ"
set xlabel "Temp/°C von HMS 100 T gemessen"
set logscale y
set xtics "10"
plot 'Temperatur über Widerstand' w lp

Nun ersetzte ich die Messwiderstände mit dem Fotowiderstand A1060 und 2,2kΩ Reihenwiderstand. Damit wird die Helligkeit in einem Bereich von -40,4°C bis ca. 60°C dargestellt.

In dunklen Situationen löst der Sensor sehr hoch auf. Leichte Dämmerung bringt das Signal von -40°C auf -20°C. Durch den Reihenwiderstand fehlt diese Dynamik allerdings im oberen Bereich. Direkte Besonnung lässt sich nur schwer erkennen. Ist dies gewünscht, sollte vor den Photowiderstand ein Filter gesetzt werden.

Um Leuchten oder Heizungen elektronisch zu steuern werden im einfachsten Fall Insel-Lösungen verwendet. Dies sind z.B. Leuchten mit Bewegungsmelder, Steckdosen mit Funkfernbedienung, Hausnummernbeleuchtungen mit Dämmerungssensor oder Termostate für Heizungen. Deutlich flexibler sind die System-Lösungen, bei denen sich mehrere Sensoren und Aktoren kombinieren lassen. FS20 von ELV ist eines dieser Systeme. Hier lassen sich beliebig viele Fernbedienungen, Dimmer, Schalter oder Ventile miteinander verbinden. Alles, was Befehle sendet, wird dabei Sender genannt. Alle Geräte, die Befehle ausführen, heißen Empfänger. Sender und Empfänger werden direkt miteinander verbunden. Drückt man eine Taste, geht z.B. das Licht im ganzen Raum an. In den Sendern werden alle Befehle programmiert und die Empfänger darauf angelernt. Für komplexere Zusammenhänge wird meistens eine Zentrale benötigt, die alle Schaltzustände kennt und damit flexibler die Empfänger steuern kann.

Zentrale

Für FS20 gibt es die FHZ-Zentralen. An einem angeschlossenen PC mit Windows-Programm stellt man ein, wie die Zentrale auf Eingänge reagieren soll. Die größten Probleme sind dabei erstens das Windows-Programm und zweitens, dass man für immer bei FS20 bleiben muss.

Mit dem USB CUL-Adapter kann jeder Rechner FS20-Signale empfangen und senden. Sehr gut geht das mit einem Raspberry Pi oder einem kleinen Server. Als Software wird in der Regel FHEM verwendet. Es handelt sich um extrem aufwändige Perl-Scripte, die massenweise Hausautomatisierungs-Systeme kennen und verbinden können. Auf Konfigurierbarkeit und Benutzerfreundlichkeit im täglichen Einsatz wurde dabei kaum Wert gelegt.

CUL_FS20

Als Ersatz für FHEM entwickelte ich CUL_FS20. Dies ist lediglich eine Klasse für node.js, die über den CUL-Adapter mit FS20-Geräten spricht. Ein kleines Script kann die Sender und Empfänger beliebig verknüpfen. Eine Webseite und weitere Funktionen lassen sich einfach ergänzen, denn dafür ist node.js gedacht. Ich habe mich dabei für Meteor entschieden, aber es geht auch genauso mit ExpressJS oder ohne Framework direkt in node.

github.com/netAction/CUL_FS20

Die Idee kam aus Sheldons und Leonards WG: Ein gigantisches Jenga-Spiel. Im Baumarkt holte ich Kantholz, besser gesagt raues Rahmenholz mit einem Nenn-Querschnitt von 40x60mm². In Wahrheit hat es nur 38x58mm². Das entspricht dem Seitenverhältnis des Originals, ist nur viel größer. Es gab eine Packung mit vier drei Meter langen Hölzern für 8€. Die Steine lies ich auf 180mm Länge zuschneiden. Eigentlich ist das 6mm zu lang, das wusste ich im Laden nur nicht, weil das Maß auf dem Etikett nicht stimmt. Jedes Rahmenholz ergab 16 Stück, also insgesamt 64 Spielsteine.

Es lassen sich 21 Etagen aufbauen, was mehr sind als in jedem käuflich erwebbaren Jenga. Wenn mal Steine fehlen, ist das kein Problem. Während des Spieles ist der Turm gut einen Meter hoch. Die rau gesägte Oberfläche stört nicht, die Steine rutschen trotzdem ausreichend gut. In der Größe funktioniert das Spiel gerade noch im Wohnzimmer oder in Kneipen. Mit noch höheren und schwereren Türmen sollte man besser in Hallen oder raus gehen. Für 8€ hat sich der Spaß auf jeden Fall gelohnt.

Schiffe auf See führen seit Jahrhunderten Logbücher. Mit ihrer Hilfe lassen sich Reisen detailliert nachvollziehen und Unwetter rekonstruieren. Auch heute sind sie selbst auf Sportbooten vorgeschrieben. Aber was sollte da wie aufgeführt werden?

Der Gesetzgeber hat keine großen Ansprüche. Alles, was „für die Sicherheit in der Seefahrt einschließlich des Umweltschutzes auf See und des Arbeitsschutzes von besonderer Bedeutung“ ist, muss eingetragen werden. Darunter fallen Unfälle. Wenn Technik kaputtgeht, muss dies vermerkt werden, damit der Schaden behoben werden kann oder zumindest der nächste Skipper bescheid weiß.

Die Logbücher dienen der rechtlichen Absicherung, der Planung und Organisation, für sportliche Ziele wie den Sportküstenschifferschein und natürlich als Erinnerung. Angegeben werden Wind und Wetter, Stempel von Häfen, Beginn und Ende der Wachen, Orte, gefahrene Strecke (Segel und Motor), was unterwegs passiert, Besonderheiten bei Charter, Defekte, Zeit der Reffs bis hin zu Einkaufslisten. Für die Crew dienen sie außerdem als Meilennachweis, deshalb sollte die Funktion an Bord eingetragen werden: Wachführer, Deckshand, Rudergänger, Navigator oder Festmacher.

Grobe Angaben finden sich im §6 Schiffsicherheitsgesetz und im Merkblatt über die Verpflichtungen der Sportschifffahrt im Hinblick auf Seetagebücher bei ELWIS.

Zur Dokumentation meiner Fahrten entschied ich mich, einen Ordner in A5 anzulegen. Es wird ein Blatt für den ganzen Törn und pro Tag ein Tagesbericht eingeheftet.

Die A4-Seite mit beiden Blättern zum Ausschneiden als PDF und Inkscape-Datei. Der Font ist Archive Garamond Standard Regular.

Letzte Woche besuchte ich einen Anfängerkurs in der Surfschule in Zingst. Am ersten Tag sollten wir auf dem Brett stehen und nicht sofort runterfallen. Am zweiten Tag übten wir das Rigg aufholen, losfahren, Wende, Halse, anluven, abfallen. Am dritten Tag gab es nur 1-2 Beaufort Wind, so dass wir die Wende verbesserten, Beach Start und Tricks übten, z.B. rückwärts und mit Schothorn voraus fahren. Obwohl wir an den drei Tagen nur eine Stunde zum Üben hatten, machte es zum Schluss schon richtig Laune, und ich wäre gerne in den Sonnenuntergang geheizt.

Nach Auf der IFA Berlin nichts neues von 2010 und Auf der IFA Berlin nichts neues 2.0 von 2011 wollte ich ja sagen, jetzt gab es etwas Neues. Aber es gab einfach nichts Neues. Fast nichts. Klar, Evolution geht immer in kleinen, kaum sichtbaren Schritten. Die Technik wird jedes Jahr hier und da ein bisschen besser, und irgendwann schaut man zurück und denkt: Wow, was hat sich geändert in den letzten zehn Jahren. Aber so eine Evolution geschieht nicht. Der 3D-Hype ist einfach wieder gestorben. Die Tablets und die unsäglich vielen Gadgets, allen voran die Kopfhörer, verschwinden einfach wieder.

Samsung, Sony und Nikon zeigten Kameras, die keine Blitze fernsteuern konnten und keine lichtstarken Zoomobjektive hatten. Die Aussage sind unisono, man arbeite an brauchbaren Kameras, aber im Moment sieht es eher schlecht aus. Nur Panasonic hatte Modelle mit diesen Funktionen. Gezeigt wurde allerdings nichts davon. Die Leute am Stand wussten nicht einmal, dass ihre Kameras das konnten, und verwiesen mich an Canon. Der Glaube an die eigene Marke sieht anders aus.

Klobige Uhren mit vielen unbenutzbaren Funktionen waren natürlich auch zu sehen, und davon wird es nächstes Jahr noch viel mehr geben. Kein Plan, was man damit soll.

Subjektiv würde ich sagen, dass der Trend weg von 3D-Bullshit, iPhone-Cases und Solar-Ladegeräten geht. Das ist prima. Statt dessen wurden mit Ultra-HD-Displays, Phablets und Studio-Lautsprechern Dinge vorgestellt, die man sinnvoll kreativ einsetzen könnte. Überhaupt wurde die Wertigkeit der Marken mehr hervorgehoben als Buzzwords. Vielleicht ist das der Anfang vom Umdenken, dass man Technik auch wieder gebrauchen können soll. Vielleicht kommt auf der nächsten IFA der Durchbruch. Eine freie und zuverlässige Schnittstelle für Ultra-HD-Displays wäre was. Und wenn es Uhren mit Rechner drin sein sollen, dann brauchbare Open-Source-Uhren. Oder -Brillen. Oder meinetwegen der Communicator-Pin von Star Trek für die Brust.