Die meisten Daten haben überlebt

Noch ein kleines Update zum letzten Beitrag: Nach vielen On-Off-Zyklen der Festplatte war ddrescue bei 100 % aber doch nicht fertig.

ddrescueview zeigte folgendes:

416,24 GB wiederhergestellt, aber knapp 84 fehlen noch. Hm, das ist ungewöhnlich schlechte Ausbeute, vor allem weil so große Blöcke fehlen. Da muss ich etwas falsch gemacht haben.

Ich höre schon meine alte Ausbildungskollegin schreien „manpage, MANPAGE!!!“

ddrescue läuft mit den Parametern (Reihenfolge zu Dramaturgiezwecken geändert)

-f -r10 -v -n

-f: force overwrite of outfile, braucht man, wenn auf eine Partition geschrieben wird
-r10: Exit after the given number of retry passes
-v: Verbose mode
-n: Skipe the scraping phase

Vielleicht sollte ich das letzte weglassen 😉

Gesagt, getan – und ddrescue läuft weiter. Im Schleichmodus werden die restlichen Daten zusammengekratzt. Um diese Schleichfahrt nicht zu blockieren, habe ich den Knockout meines Scripts auf 2 Stunden gesetzt. Nach ein paar weiteren Tagen sieht es wie folgt aus:

Das würde ich als Erfolg bezeichnen. Mit dem Hintergrund, dass die erste Partition der Platte eine versteckte EFI-Partition mit 200 MB ist, sollten die Userdaten vollständig lesbar sein.

Das Volume ließ sich dann auch wieder mounten. Um auf Nummer sicher zu gehen, habe ich aber trotzdem noch ein Image der Partition gezogen.

dd if=/dev/sdxy of=/media/foo/bar/image.bin bs=64K

macht den Job. Wichtig ist, die Blocksize anzugeben, da sonst gefühlt Byteweise kopiert wird und so der Durchsatz unterirdisch ist – ohne Parameter dümpelte der Kopiervorgang von USB 2.0 nach USB 2.0 mit 4 MB/s herum, mit 64K bei 38 MB/s. Mehr geht über die Schnittstelle fast nicht.

ddrescue. aggressiv.

„Nein“ wäre die richtige Antwort gewesen. „Nein“ zur Frage, ob ich eine Festplatte wiederherstellen kann, die vor meinen Augen nochmal fallen gelassen wurde.

„Macht der das was?“

JA, verdammt nochmal – Festplatten (also „klassische“ mit Magnetscheiben) sind mechanisch empfindliche Komponenten.

Naja. Eine zweite Platte für die Wiederherstellung hat er immerhin schon besorgt, also versuche ich mein Glück. Also ein Live-Linux in das olle Thinkpad geworfen und ddrescue gestartet.

Quelle: 500 GB 2,5 Zoll Western Digital Blue, Ziel: 1 TB 2,5 Zoll Seagate.

Zunächst ging es auch ordentlich schnell und ich dachte, der begrenzende Faktor wäre das USB 2.0 am Rechner. Doch auch mit der extra georderten USB 3.0 Expresscard ging es nach ein paar Klimmzügen (zusätzliche Versorgung der Festplatten) nicht wirklich schneller.

Nach den ersten paar Gigabyte sackte die Leserate aber auf mehrere 100 kByte/s ab. Nicht so schlimm, wäre da nicht folgendes Geräusch:

(das nach 10 Sekunden)

Wäre da nur das Geräusch, könnte man vielleicht noch damit leben, aber ddrescue macht nur noch eines: Fehler für Runde zwei melden. Das bringt einen nicht weiter. Also Platte weg und wieder ran. Die ersten paar Stunden mache ich das noch manuell, dementsprechend haben sich knapp 100 GByte Lesefehler und ein wenig Frustration angesammelt. Grmpf. Dabei fiel auf, dass die ersten 30 Sekunden die Übertragungsrate mit 15-30 MByte/s noch relativ hoch war, danach sank sie schlagartig ab und schwankte zwischen 65 und 300 kByte/s.

In einer Woche (Abends, musste in der Nähe sein) kamen so etwa 90 GByte von Platte A auf Platte B. 150 GByte wurden als nicht lesbar markiert.

Um nicht dauernd den USB-Stecker ein- und ausstecken zu müssen, habe kam eines meiner Schubladen-Projekte zum Einsatz, der (verbuggte) USB-Switch. Mit einem Mit einem TS3USB221 (sehr klein und bescheiden zu löten) und einem IRLML2244 lässt sich das angeschlossene Device mit dem PC verbinden und trennen. Die Verbindungsfolgen werden erwartungsgemäß nicht eingehalten und durch einen Denkfehler und zu wenig Koffein schaltete die aktuelle Version entweder die Versorgung oder USB durch. Fädeldraht hat es zumindest vorübergehend gerichtet. Mit einem Schalter ausgestattet bleiben nun die Stecker heile.

Aber zurück zur Datenrettung. Zwei Gedanken: Die Platte alle 30 Sekunden pauschal zu trennen erhöht zwar die Datenrate, aber auch die elektromechanischen Zyklen, was der Lebensdauer nicht wirklich zuträglich ist. Gleichzeitig kommt die Platte nach einem Aussetzer nicht mehr hoch. Sie muss neu gestartet werden. Das kann man überwachen, indem man die Größe der Logfile von ddrescue prüft. Wächst diese stark an, ist etwas im faul. Ferner beendet sich ddrescue automatisch, wenn die Platte sich komplett abwirft.

So viel zum Wissen, aber wie kommt diese Information zum USB-Switch? Am einfachsten wäre es ja, den USB-Port selbst aus- und wieder einzuschalten. Geht in manchen Systemen, aber eine mittelkurze Recherche zeigte: die Erfolgschancen sind eher gering.

Also doch irgendwie anders. Hm. Der Laptop ist zu jung für den Parallelport, einen Microcontroller dafür zu programmieren ist mir ehrlich gesagt auch zu blöd. Hm, DTR und RTS lassen sich doch üblicherweise durch Software schalten und einen USB<>UART-Wandler, bei dem zumindest RTS herausgeführt ist, liegt auch herum.

Unter Linux ist doch alles eine Datei, also sollte es doch ein Leichtes sein, das Flag zu setzen. Leider nicht ganz. ioctl macht zwar genau das, aber es ist nicht persistent. Sobald das Programm sich beendet, wird der Port geschlossen und RTS/DTR ist wieder low. über stty schafft man es zwar auch irgendwie, aber mein Shell-Script begann eh anfangen, ziemlich übel zu stinken.

Nachdem desinfec’t mit Python kommt – warum nicht damit? Mit pyserial kann ich zumindest unter Windows schon einmal alles machen, unter Linux klappt es auch auf Anhieb.

Mittlerweile sieht das Setup so aus:

Die Platte liegt (ich weiß, nicht ganz ideal) auf einer Schütte, der Lüfter hält sie kühl. Am Notebook hängt der USB-Stick mit Scripts und Log (wichtig, da im Notebook kein persistenter Speicher ist), daneben der USB-Switch, der mit dem RTS des USB<>UART-Wandler verbunden ist.

Das Python-Script macht aktuell folgendes:

Verbinden der Platte und warten, bis /dev/sdx (also die Platte) existiert. ddrescue mit den entsprechenden Parametern als subprocess starten. Während es läuft, also .poll() des Prozesses keinen Exitcode ausweist. Weiter wird geprüft ob die Logdatei anschwillt. Dank Caching ist das leider nicht ganz so zielführend, aber immerhin. Das dritte Kriterium ist die Laufzeit. Ist die Datenrettung länger als 10 Minuten aktiv, naja – ich bin nicht stolz drauf. Tritt eine der drei Bedingungen ein, wird die Platte getrennt und gewartet (falls nicht schon passiert), bis ddrescue fertig mit dem Schreiben der Logdatei ist. Nach einer weiteren Wartezeit geht das Spiel von vorne los:

rescue.zip (weil WordPress mir Python-Scripts verbietet)

Für Schäden, die das Script verursachen kann, übernehme ich keine Haftung.

In nicht ganz 24 Stunden sind so nun weitere 130 GByte in Richtung Ersatzplatte gewandert. „Nur“ 35 weitere Gbyte wurden als defekt markiert.

Ob die Aktion erfolgreich gewesen sein wird, kann ich erst in knapp 280 GByte sagen und hoffe, dass auch so viel davon gelesen werden kann.

Abschließend kann ich nur mal wieder sagen: Kein Backup? Kein Mitleid!

…und er loggt doch.

Nachdem ich gestern nun die Dose des Neo geöffnet habe, gab es nichts mehr zu verlieren.

Da die Leiterbahn zum (de-)aktivieren des externen Flashs auch unter dem GNSS-Chip mit Masse verbunden ist, muss der erst einmal runter. Ich habe zwar schon einen BGA mit knapp 1200 Balls und extremer thermischer Masse erfolgreich getauscht, allerdings mit entsprechendem Equipment. Bei Tausch von kleinen QFNs habe ich mich bis jetzt aber erstaunlich blöd angestellt. Entweder zu viel Flussmittel oder zu viel Lötzinn. Dabei tanzt der Chip beim Erhitzen lustig vor sich hin, senkt sich aber nicht richtig ab. Dann ist ein Re-Rework fällig. Schlecht fürs Material aber meistens klappt es.

Aber zuerst muss der IC runter. Mit Heißluft bei etwa 380-400 °C und niedrigem Luftstrom (damit es keine anderen Bauteile wegpustet) um die Bauteile kreisen um die Komponenten nicht zu schnell zu erwärmen. Kurz nachdem das noch vorhandene Flussmittel verflüssigt, sieht man auch eine leichte Glanzveränderung am Lötzinn – der „sweet spot“ zum Herunterpicken der Bauteile ist kurz danach.

Nach etwas Geduld zum Abkühlen der Leiterkarte sieht man, dass nur ein einziger verdammter Pin mit der Massefläche verbunden ist. Man muss nicht raten, welcher das ist:

Mit etwas Flussmittel und Entlötlitze kommt das bleifreie Zeug zunächst runter, um es anschließend mit einer dünnen Neuauflage Sn60Pb40 zu ersetzen. Dabei habe ich den Pads außenherum mehr Zinn gegeben als der Massefläche unter dem Chip. Natürlich darf das Auftrennen der Masseverbindung zu Pin 29 nicht fehlen. Wer den Unterschied zwischen bleifrei und bleihaltig nicht kennt: Bildvergleich – bleifrei (oben) ist ziemlich matt, bleihaltig glänzt deutlich stärker:

Zwischen dem Verzinnen und wieder Bestreichen mit Flussmittel einmal mit Isopropanol waschen – Beim Ent-, Ver- und wieder Entzinnen entsteht Zunder und manchmal backt das Flux fest – das will man nicht unter Bauteilen haben. Anschließend ist der Chip dran, der ebenfalls vom Bleifrei-Lot befreit wird. Mit dopptelseitigem Klebeband auf dem Tisch bleibt er auch nicht am Lötkolben hängen.

Hier im Prozess: vertrocknetes Flux und noch nicht ganz verzinnte Pins. kleine Zinnkleckse auf der Massefläche (hier rechts oben) sollten entfernt werden, da sie den Lötprozess stören.

Nun kann der IC wieder platziert und verlötet werden. Wieder mit Heißluft mit wenig Pust und schön warm. Das Ergebnis ist gut aber nicht perfekt – der Käfer ist etwas verschoben, was aber kein Problem sein sollte:

Um vorab zu testen ob der Empfänger noch funktioniert, habe ich Pin 29 wieder gebrückt und das Modul mit Strombegrenzung (!) an den PC angeschlossen. Alles kommt hoch und nach ein paar Minuten habe ich einen GPS-Fix. Zu Glonass-Empfang lässt sich das Teil aber nicht bewegen, vielleicht aufgrund des fehlenden Shieldings?! 😉

Ok, Grundlegend funktioniert es also, aber wird der Empfänger auch mit externem Flash spielen? Ich konnte einen QSPI-Flash von Winbond ergattern. Mal schauen, ob es funktioniert.

Laut Hardware Integration Manual des UBX-G7020 (!) ist die Anschlussbelegung wie folgt (ob sie auch mit dem M8030 funktioniert?):

  • PIO0 (25) -> DI/IO0
  • PIO4 (26) -> CLK
  • PIO2 (27) -> !WP/IO2
  • PIO1 (28) -> DO/IO1
  • PIO5 (29) -> !CS
  • PIO3 (30) -> !HOLD/!RESET/IO3

GND sollte klar sein, Vcc habe ich aus Ermangelung anderslautender Tatsachen einfach an die Versorgung des Chipsatzes geklemmt.

Wieder ans Netzteil mit Strombegrenzung geklemmt: Keine Auffälligkeiten – was aber noch nicht heißt, dass es auch funktioniert. Die Wahrheit erfährt man erst, wenn man den Speicher nutzen kann, also ran an den PC und u-center wieder öffnen. Die Firmware findet sich – im Gegensatz des vollen Datenblatts – auf der Website von u-blox. Nach Anstoßen des  Updates und nicht ganz einer dreiviertel Minute warten liegt schon fast ein NEO-M8N auf dem Tisch (wären da nicht die Fädeldrähte):

Nun funktioniert auch das Logging – Mission accomplished! 🙂

u from the blox

Ich wollte schon immer mal mit GNSS-Modulen von u-blox arbeiten. Mittlerweile liegen auch ein paar Module herum. Beim „aktuellsten“ sollte es ein NEO-M8N werden, hauptsächlich, weil es relativ stromsparend in den internen Flash loggen kann und auch ansonsten relativ viel zu bieten hat.

Da die Module zwar direkt vom Hersteller erhältlich, in kleinen Stückzahlen aber sehr teuer sind, ein Blick auf eBay. Mit Antenne, kleiner Leiterkarte und und Versand mit dem Namen „GY-GPSV3-NEO“ gibt es sie schon für um die 12 Euro, also her damit! Bis es der Empfänger aus China hierher geschafft hat dauert zwar 4-8 Wochen, ohne besonderen Leidensdruck kann man das aber gut abwarten.

Packung auf und mit einem USB<>UART-Adapter an den PC – nach kurzer Zeit gibt es einen Fix und ich kann zusehen, wie die Position im Umkreis von ein paar Metern umher eiert, so weit, so gut.

Als ich in u-center (der Software zum Testen und Konfigurieren der Empfänger) Logging testen wollte passierte – nichts.

Ok, vielleicht ist eine alte Firmware drauf. Es gibt eine neuere, diese lässt sich aber nicht flashen, auch mit verschiedenen Einstellungen. Hmpf. Bin ich einem Fake aufgelaufen?

Wie sich herausstellt: ja!

Schaut man sich das Label auf dem Modul an, fällt auf, dass das Firmenlogo ausgefranst und alle runden Symbole nicht wirklich rund sind. Die Schrift passt ebenfalls nicht. Hmm, warum hat das Modul auf der eBay-Seite eigentlich die genau gleiche Seriennummer? Ist das die Nummer für die gesamte Serie?!? Klickt man sich durch die Google-Bildersuche sticht ins Auge, dass alle Module eine Datamatrix haben. Mein Modul dagegen hat einen QR-Code. Was steht da eigentlich drin? Kurz mit dem Handy gescannt: „NEO-6M-0-0001 […]“ – ich dachte, das wäre ein M8N? Nanu? Gibt man dem Modul Strom, nachdem es per UART am PC angeschlossen ist, bekommt man Infos vom Bootloader. Dort steht wiederum M8:

$GNTXT,01,01,02,u-blox AG - www.u-blox.com*4E
$GNTXT,01,01,02,HW UBX-M80xx 00080000 *43
$GNTXT,01,01,02,ROM CORE 2.01 (75331) Oct 29 2013 13:28:17*4A
$GNTXT,01,01,02,PROTVER 15.00*01

eBay-Käuferschutz zum Glück bekomme ich, nachdem mich der Händler dann doch nochmal versucht abzuziehen („Bitte den Fall schließen, damit wir das Geld auszahlen können“ – ja ne, is klar), kam das Geld zurück. Aber was nun mit dem Modul? Richtig nutzlos ist es nicht, aber doch irgendwie – weil es eben die Funktionen, für die ich es gekauft habe, nicht kann.

Aber wenn da schon ein M8 drin ist, dann sollte das doch grundsätzlich funktionieren. Gleichzeitig wäre auch interessant, was da überhaupt drin ist. Im Forum von u-blox konnte ich zumindest ein Foto mit Original und Fälschung finden. Auf dem Original sitzt ein 25Q16DV (QSPI-Flash) von Winbond, auf dem Fake nicht.

Also runter mit dem Kopf! Aber bitte so, dass es danach noch funktioniert.

Hier mal eine kleine und überaus dilettantische Collage des Shieldings von allen vier Seiten:

Am gleichmäßigsten geht es wohl runter, wenn man alles mit Heißluft erwärmt und dann den Blechdeckel abhebt. Bei meinen Fähigkeiten rutscht es in der Regel aber erst mal zur Seite und nimmt ein paar SMD-Komponenten bei denen man nie wieder herausfindet, wie sie mal drauf waren.

Nachdem das Shielding nur an ein paar Punkten aufgelötet ist, geht es auch mit dem Lötkolben. Lötzinn als Wärmebrücke auf das Blech, Schraubendreher in den Spalt einklemmen und anschließend erhitzen und vorsichtig hebeln. Leider lässt sich die Leiterkarte erstaunlich leicht delaminieren, hat es aber augenscheinlich ganz gut überstanden:

Kein Flash. In den Unweiten des Internets lässt sich keine Pinbelegung des M8030-KT finden. Wohl aber des Vorgängers G7020 (im Hardware Integration Manual, um zumindest ein Suchwort zu geben). Die Chips gleichen sich der Beschaltung ziemlich stark – warum sollte man auch ein bestehendes – durchaus komplexes – Design ohne Not ändern?

Wie auch immer, Pin 25-30 (rechts oben am Chip im Bild) sind IOs und werden – zumindest beim 7020er – für externen Speicher genutzt. Pin 29 definiert, wenn auf GND gezogen, dass nur der interne ROM verwendet wird. Die 3 Pins darunter legen in dieser Konstellation ein paar Konfigurationen fest. Das Bild im u-blox-Forum korreliert zumindest soweit man es erahnen kann mit dieser Information. Wäre nicht dieser dämliche Pin 29 mit der Massefläche verbunden. Bleibt zu hoffen, dass er das nur von außen und nicht auch von hinten ist. Ich befürchte aber, …

Ein Schnitt mit dem Skalpell später und „pieeep“ sagt das Multimeter – meh. 🙁

Ende für Teil 1.

MediaWiki 1.28.1

Die Media-Wiki-Installation hier ist jetzt nach langer Zeit wieder aktuell.

Einiges gefällt mir ganz gut, an anderen Dingen muss noch gearbeitet werden. Übergangsweise habe ich den von Wikipedia bekannten Multimedia-Viewer installiert, da es momentan keine Erweiterung mit Highslide Js gibt, die mir halbwegs gefällt (oder zumindest gut funktionsfähig ist).

Das wichtigste jedoch: Sollte irgendetwas auffallen, das nicht funktioniert oder komisch aussieht, bitte hier in den Kommentaren oder per Mail melden. (Vielen Dank schon einmal!). Allgemein gilt: Wenn jemand Fehler (technisch, inhaltlich oder anderweitig) findet, ich freue mich über jeden Hinweis!

Kein Funk ist auch keine Lösung

Die nRF24L01P sind beliebt und günstig, weshalb hier seit längerem auch ein paar Module mit den Chips herumliegen.

Getrieben durch das Vorhaben eine Wetterstation zu bauen habe ich zwei jeweils an einen Mikrocontroller gehängt.

Nachdem die Übertragung (endlich) funktionierte, ging es daran die Reichweite zu testen. Im ersten Einfach-Programm ließ ich im Sender jede Sekunde ein Paket mit Counter und den Werten des bereits angedengelten Luftfeuchte- und Temperatursensor senden.

Auf der Gegenseite lediglich eine LED, die bei jedem empfangenen Paket toggelt. Bei 1 Mbit/s und 0 dBm war schon im Treppenhaus schluss, ich hoffte aber noch, dass es im Garten noch bzw. wieder klappt, da quasi Sichtkontakt besteht. Nichts. Grmpf.

Laut Datenblatt gewinnt man mit 250 kbit/s gegenüber 1 Mbit/s 9 dB an Sensitivity, was ein wenig Quell der Hoffnung war. Leider hat das auch nicht so wirklich geklappt.

Um zumindest einen Erkenntnisgewinn zu haben, ging es in den Park nebenan um dort auszuloten, wie weit es überhaupt geht. Im ersten Versuch schaffte ich knapp 190 Meter im freien Feld und bei gut aufeinander ausgerichteten Antennen. Ohne Ausrichtung war bei etwa 70 Meter gerade noch zuverlässiger Empfang möglich.

Allerdings hatte ich keine Information, wie oft tatsächlich übertragen werden musste, um Daten von A nach B zu bekommen. Schließlich verwenden die Module Handshaking mit Retransmission. Eine Anzeige musste her. Also schnell das alte und zerkratzte Nokia-Display ausgegraben und angeschlossen. Der eingestaubte Code funktionierte auch fast auf Anhieb.

Da der Empfänger von sich aus nicht wissen kann, wie viele erfolglose Übertragungen es gab werden die Werte im Sender kumuliert in den Sendepuffer geschrieben und nach einer erfolgreichen Übertragung wieder zurückgesetzt. Auf dem Display sieht es dann wie folgt aus:

Ob es wirklich sinnvoll ist, die Temperatur und Luftfeuchtigkeit darzustellen, sei mal dahingestellt, aber warum wegwerfen, was der Sensor hergibt?

Neuer Tag, neues Glück? Mitnichten. Vielleicht lag es am Wetter, vielleicht an der Verdeckung durch Parkbesucher oder am Display – die Reichweite war niedriger. Zuverlässige Datenübertragung ohne Antennenausrichtung war bis knapp 55 Meter möglich, mit (und mit etwas Glück) etwa 85 Meter.

Die Verbindung zwischen geplanten Aufstellorten von Sender und Empfänger war nach wie vor nicht möglich.

Nächste Schritte? Am liebsten würde ich die nRF-Module verwenden. Die Software läuft und die Hardware ist schon da. Interessant wäre, wie sich die Antennen verbessern ließen. Ohne eine vernünftige Möglichkeit, die abgestrahlte Leistung oder das Stehwellenverhältnis zu messen wird es schwierig. Durch den Park laufen tut zwar gut ist aber nicht so richtig vergleichbar. Messequipment für solch einen Zweck zu kaufen steht in keiner Relation. Vielleicht muss ich mal mit ein paar bekannten HAMs reden.

Reibung

Ohmannohmann, damit hätte ich nicht gerechnet.

Die Installation vom Wiki hat schon länger ein Update nötig, 1.25 liegt auch schon länger auf dem Server, aber unbenutzt. Nun habe ich mich mal wieder dran gewagt. Die absolute Minderheit gab es aktualisiert im Repository von Mediawiki, die Mehrheit nicht. Zwar würde die Seite auch ohne die anderen Erweiterungen halbwegs funktionieren, aber wenn man sich einmal an Komfort gewöhnt hat, will man ihn nicht wieder abgeben.

Die Anzeige der aktuellsten WordPress-Posts habe ich selber mal gehackt. Das gibt es in dieser Form nicht zum herunterladen. Den Code habe ich auf die neue Extension-API angehoben und noch ein paar mehr Funktionen eingebaut. Nun muss man nur noch den Ort der Config-Datei und den externen Basispfad angeben. Über Parameter im Pseudo-HTML-Tag lassen sich Optionen mitgeben. Die Auswahl von Kategorien muss ich noch implementieren. Wenn das funktioniert, wird der Code freigelassen.

MathJax – schöne Formeln! Nur leider ist das Sammelsurium aus über 30000 PNG-Dateien eine Seuche. Aufgrund der Clustergröße macht das aus Netto 10 MB stolze 150 MB. Durch den Overhead von FTP dauert der Upload gefühlt Stunden, dafür dass es im Endeffekt nur von einer Minderheit genutzt wird (standardmäßig spuckt es entweder HTML oder SVG aus) – absoluter Bullshit. Also die ganzen Dateien in eine Zip geworfen und ein PHP-Script geschrieben, das sie – aufgerufen mit dem Pfad als Parameter – wieder ausspuckt. Die Javascript-Datei, die auf die Bilder linkt angepasst und fertig ist der Lack. Ja, Zip ist dafür nicht ideal aber gut genug, bis mir etwas besseres einfällt.

Dann wäre da noch Highslide. Was für ein instabiles Flickwerk – nicht Highslide selbst, sondern die Integration. Die Bilder werden über reguläre Ausdrücke aus dem fertigen HTML extrahiert, anhand des Dateinamens (oder Links) die „Vollversion“ ermittelt und dann mit search & replace (genau genommen regex replace callback) ersetzt. Das ist so ziemlich das inkompatibelste was man machen kann. Dementsprechend habe ich das bei jedem kleinen Update patchen dürfen. Jetzt will ich es – wenn möglich – ein bisschen eleganter implementieren. Zur Not von Null weg.

GeSHi Syntax Highlight. Aktuell noch das größere Sorgenkind. MediaWiki hat 2015 auf Pygments umgestellt. Schön für sie und vermutlich die Performance aber hier gibt’s leider kein Python. Richtigen Ersatz habe ich noch nicht gefunden. Aber die Suche geht weiter.

Vielleicht schaffe ich das Update ja bis zum Geburtstag von der Homepage Anfang April.

Übrigens, als Randnotiz: die Homepage ist teurer geworden. Lt. Hetzner durch den starken Dollar – org-Domains werden durch die ICANN verwaltet und dadurch in USD gehandelt. Statt 12,90 Euro sind es jetzt 15,35 Euro im Jahr. Bringt einen nicht um aber immerhin eine Steigerung von 19 %. Dafür könnten sie ja zumindest Cronjobs und/oder Python in den kleineren Tarifen freischalten 😉

Sei helle!

Die Verwandtschaft hat gebaut. Beim Rundgang ist mir aufgefallen, dass mein Cousin relativ viele Leuchten mit GU10-Halogenlampen hat. Auf die Frage, ob ihm das nicht zu viel kostet meinte er, dass das nur einen Cent pro Stunde ausmacht und es ihm deshalb relativ egal wäre. „Wenn er meint“, dachte ich mir.

Als ich in meine Wohnung eingezogen bin, gab es überall LED. Wo noch konventionelles Leuchtobst installiert war, wurde spätestens mit dem ersten Defekt modernisiert. Außer beim Kühlschrank, Backofen und Badezimmerspiegel bin ich mittlerweile komplett auf der Technologie und beim Stromverbrauch (obwohl der PC viel läuft) deutlich unter dem Durchschnitt meines E-Werkes.

Es hat mir dann doch keine Ruhe gelassen. Also raus den Rechner!

Aber zuerst einmal Vergleichsobjekte finden. Ohne eine Marke bevorzugen zu wollen, habe ich mir zwei vergleichbare Leuchtmittel von Osram rausgesucht:

Die LED ist zwar etwas heller, hat aber einen etwas schlechteren CRI, deswegen behandle ich sie in Sachen Lichtausbeute einfach mal gleich.

Bei einem Strompreis von etwa 28,75 ct/kWh (Quelle: Bundesverband der Energie- und Wasserwirtschaft e.V.), kostet die Halogen 1,4375 ct/h und die LED 0,1236 ct/h. Ja, recht hatte er – aber trotzdem lag er falsch. Pauschal hört sich „ein Cent“ wenig an, aber 11,6-mal ist dann doch eine andere Hausnummer, vor allem, da der Cent nur für eine Lampe gilt.

Ein guter Freund von mir hatte bis jetzt auch immer GU10-Halogen in seiner Wohnung. Bei seinem Umzug haben wir ihm nahegelegt, doch auf LED zu wechseln. Im Esszimmer hat er 4 Lampen, im Wohnzimmer 8 in der Leuchte stecken und zumindest letztere ist am Tag etwa 4 Stunden an. Rechnen wir doch einfach mal aus, was nur das Wohnzimmer in einem Jahr jeweils kostet. 4 Stunden täglich, 365 Tage im Jahr (Urlaub, Sommer/Winter außen vor gelassen) sind 1460 Stunden, also:

  • Halogen: 8 * 1460 h * 1,4375 ct/h = 167,90 Euro/Jahr
  • LED: 8 * 1460 h * 0,1236 ct/h = 14,44 Euro/Jahr

Das ist schon einmal ordentlich, allerdings noch nicht die ganze Wahrheit. Das Stichwort ist „total cost of ownership“. Lampen gehen kaputt und müssen hin und wieder getauscht werden. Die Produktbezeichnungen bei einem Onlineversandhaus eingehackt ergibt: Halogen im 2er-Pack für 5,49 Euro, die LED-Lampe einzeln für 5,99 Euro. Bei dem beispielhaften 1460 h Betrieb sind 73 % der Halogenlampen und 9,73 % der LED-Lampen fällig. Zusätzlich muss man dumm-statistisch gerechnet 5,84- (Halogen) gegen 0,78-mal (LED) pro Jahr auf die Leiter steigen. Rechnet man einfach mal 15 Euro Stundenlohn und 20 Minuten Einsatz (Neue Lampe kaufen, freischalten, Spannungsfreiheit feststellen, Leiter holen, Lampe tauschen, Wiedereinschalten, testen, Leiter aufräumen, kaputte Lampe wegwerfen), kommt man auf zusätzliche Betriebskosten von:

  • Halogen: (5,49/2 Euro + 20 min/(60 min/h) * 15 Euro/h) / (2000 h) = 0,0038725 Euro/h
  • LED: (5,99 Euro + 20 min/(60 min/h) * 15 Euro/h) / (15000 h) = 0,0007326 Euro/h

Und da ist die Gefahr von Arbeitsausfällen durch Unfälle noch gar nicht mitgerechnet 😉

Aber auch hier ist Halogen 5,3-mal teurer als LED. Aufs Jahr und Wohnzimmer gerechnet ergeben sich hier „Wartungskosten“ von immerhin 45,23 Euro (Halogen) bzw. 8,56 Euro (LED).

Unterm Strich kostet also nur die Beleuchtung des Wohnzimmers mit Halogen 213,13 Euro im Jahr, mit LED sind es lediglich 23,00 Euro im gleichen Zeitraum.

Natürlich ist in meiner Rechnung nicht der vollständige ökologische Fußabdruck, aber ich würde mal vermuten, dass die LED ebenfalls günstiger wegkommt, weil weniger produziert werden muss und weniger Müll entsteht.

Einen weiteren Punkt habe ich ebenfalls nicht berücksichtigt: Die Halogen-Lampe ist nach den 2000 Stunden kaputt, also bei 0 Lumen, bei der LED-Lampe gibt der Hersteller nach Nennlebensdauerende noch 70 % des originalen Lichtstromes an. Zwar nicht mehr ganz so knackig aber besser als nichts.

Ich fahre, also bin ich

Autonomes fahren ist in aller Munde, die meisten Hersteller sind aber eher zurückhaltend. Einzig Tesla ist innovativ, mutig oder dumm genug mit seinem „Autopilot“ vorauszupreschen und hat bereits einige Unfälle, viele beinahe-Unfälle und bereits  Todesopfer gefordert.

Im ersten Fall, weil das hauptsächlich kamerabasierte System unter schwierigen Lichtbedingungen einen querenden Lastwagen (was softwareseitig noch nicht unterstützt wurde) fälschlicherweise als Schild erkannt hat. Mobileye, der Hersteller der verwendeten Bildauswertungsplattform im Fahrzeug wies die Schuld von sich und beendete die Zusammenarbeit mit dem Automobilhersteller. Wohl aus Selbstschutz, denn auch andere Hersteller verwenden deren Systeme für Assistenzsysteme.

Die Bundesanstalt für Straßenwesen hat zumindest dem System im Model S als eine „erheblich Verkehrsgefährdung“ (keine Primärquelle gefunden) bezeichnet. Einfach mal die Zusammenfassung hinter dem Link lesen, das reicht. Man muss dazu sagen: der Verkehr in den USA ist sicherlich anders, Highways sind langsamer und zusätzlich sind die Geschwindigkeitsunterschiede zwischen den Fahrzeugen sicher niedriger. Bei fehlender Straßenmarkierung einfach dem Vordermann folgen (und bei dessen Einscheren nach dem Überholen das Fahrzeug nebenan abdrängen/rammen) ist allerdings mehr als stümperhaft.

Zumindest hat Tesla den Namen für sein System relativ gut gewählt: „Autopilot“, nicht „Auto(nomous)drive“. Ein Autopilot in der Avionik sorgt in aller Regel für eine stabile, gerichtete Fluglage und Kurs, nimmt dabei aber keine Rücksicht auf andere Verkehrsteilnehmer. Er nimmt den Piloten zwar Arbeit ab, ersetzt sie aber nicht. Obwohl die Systeme mittlerweile auch das Landen übernehmen können, müssen die Piloten aufmerksam bleiben, überwachen und wenn es sein muss eingreifen. Wie würden Passagiere reagieren, wenn sich so etwas im Cockpit abspielen würde?

Wie Piloten dürfen auch Benutzer des stark ausgebauten Fahrerassistenzsystems nicht die Aufmerksamkeit auf das Verkehrsgeschehen verlieren.

Das ist schwierig und verlangt umdenken. Ich war zwar noch nicht in einem so stark automatisierten Fahrzeug unterwegs, allerdings in welchen, die bei denen man auf der Autobahn schon fast loslassen könnte: Abstandsgeregelter Tempomat, Spurhalte- &  Seitenassistent, Schildererkennung und den ganzen anderen Schnickschnack.

Solange man sich auf der Standardautobahn in halbwegs absehbaren Situationen befindet, super entspannt und man fühlt sich sicher. Die einzige Frage, die ich mir mittlerweile stelle: wie gut ist die Illusion?

Der Abstandsregelautomat bremste mich aus, als in einer langgezogenen Linkskurve das vorausfahrende Fahrzeug links abbog (und deutlich langsamer wurd). Für die hinter mir  muss ich wohl wie der dümmste Fahrer aller Zeiten gewirkt haben. Die Straße frei, und der Vollpfosten in der dicken Karre bremst. Für das Radar war das aber plausibel, weil der Verkehrsteilnehmer noch vor mir war.

Die nächste, schon öfter erlebte Situation: Spurhalteassistenz in Baustellenbereichen mit gelben und weißen Markierungen und nicht optimale Sicht. Das Auto wollte den weißen Spuren folgen. Mein Lenkeingriff war noch nicht grenzwertig aber doch unangenehm. Mittlerweile mach ich das System in solchen Situationen aus – nur wenn es wirklich frei ist, mach ich etwas „thrillseeking“ – wird die richtige Spur diesmal erkannt? Nein. Ratsch. Auch spontanem Ausweichen (habe ich zum Glück noch nicht testen „dürfen“/müssen) wäre damit sicher ein „Spaß“: „oh, du verlässt deine Spur – moment, ich mach mal“. Blech oder im Zweifel Leben.

Von der Schildererkennung wurde ich immer wieder enttäuscht. Immer wieder wurden Aufhebungsszeichen nicht erkannt, Ortsschilder schon gleich gar nicht und das Display sagte 80 innerorts. Mit Verstand im Standby würde das immerhin 120 Euro und einen Punkt kosten.

Da ist mir der Seitenassistent noch am liebsten. Zumindest bei einer Marke. Ist ein anderes Auto im „Anmarsch“ und man setzt den Blinker, holt sich der Außenspiegel Aufmerksamkeit. Beim ersten Mal habe ich mich gewundert, wo denn der Blitzer stand. Ohne Blinker und Gefahr beim Ausscheren glimmen die LEDs nur. Sehr komfortabel, aber auch zuverlässig? Ich bin mir sicher, viele kommen irgendwann an den Punkt, an dem sie dem System sprichsprichuwörtlich blind vertrauen und keinen zweiten Blick wagen. Was, wenn in solchem Fall die Anzeige durch einen schlechten Kontakt ausfällt? Die Folgen können fatal sein.

Das waren jetzt nur drei ADAS-Systeme und auch nur eingeschränkt gültige Erfahrungen. Aber sie zeigen dass sie Aufmerksamkeit noch nicht ersetzen können.

Beim autonomen Fahren muss intensive Datenfusion stattfinden, sich einzig auf eine Informationsquelle zu verlassen wäre grob fahrlässig. Bliebe ein Blatt an einer Kamera kleben, wäre es plötzlich vorbei mit dem Selbstfahrer, genauso wie ein mitgenommener Vogel vor dem Radar. Auch können Sensoren ausfallen oder unbrauchbar Informationen liefern, wie GPS im Tunnel oder Kameras bei Nacht. Man darf aber au bei nicht außer Acht lassen, dass Daten bewusst oder unbewusst manipuliert werden können. Der übelste mir bekannte Fall ist, dass ein Sicherheitsforscher aus größerer Entfernung einem LIDAR ein Objekt in wenigen Metern Entfernung vorgaukeln konnte. Die Steinewerfer der nächsten Generation sind also mit Laptop und Laser bzw SDR unterwegs?

Zu den selbstgewonnenen Daten kommen noch (in aller Regel vorverarbeitete) Fremddaten: TMC, Karten (nicht umsonst haben sich die dt. Automobilhersteller zusammengetan und Here Maps gekauft) und X-to-Car-Kommunikation. Besonders letzteres dürfte meiner Meinung eine erhebliche Rolle spielen, um Verkehrs- und Streckendaten auszutauschen und dem Blechfahrer genügend Informationen für die Fahrt zu geben. Das Problem ist hier sicher das flächendeckende Vorhandensein entsprechender Kommunikationspartner, denn Weitblick und Urteilsvermögen ist etwas, das man Software nur nur sehr schwer beibringen kann.

Eine Firma, die sich in letzter Zeit intensiv mit Supercomputing beschäftigt, möchte autonomen Fahren auf Basis von künstlicher Intelligenz bzw. deep learning entwickeln. Das Problem ist hier sicherlich, dass das Verhalten nicht wie bei konventionellem Quellcode durchblickt werden kann. Zwar lässt sich das Verhalten durch Simulation bzw. Stimulation erfassen, man bekommt allerdings ein Beobachterproblem: alle möglichen Konstellationen können faktisch nicht abgedeckt werden. Zudem: was, wenn der KI (un-)absichtlich schlechtes Verhalten beigebracht wird? Oder was, wenn Visionen aus Hollywood Wirklichkeit werden und der „Ghost in the machine“ Menschen als Gefahr ihrer selbst erkennt? Nicht, dass ich neuronale Netze grundsätzlich für schlecht halte, es ist tatsächlich ein extrem interessantes Feld – nur habe ich ehrlich gesagt kein gutes Gefühl, mein Leben in die Hand eines künstlichen Gehirnes mit der Intelligenz eines 2-3-jährigen Kindes zu legen.

Auch bei den klassischeren entwickelten Systemen hätte ich als „fahrtüberwachender Passagier“ ein Problem: Man weiß nie so genau, was das Auto in seiner Umgebung erkannt hat, siehe meine ADAS-Erfahrungen von oben. Um ein besseres Gefühl zu haben, würde ich gerne wissen, was das Fahrzeug im „sieht“ und was es für die nächsten Sekunden plant. Die hierfür benötigten Daten sind vorhanden, eine entsprechende Visualisierung habe ich schon gesehen – aber nicht im Produkt für Kunden. Ich vermute, dass dies die Kontrollfunktion der Benutzer verbessert und eine bessere Akzeptanz bringen kann, da vermutlich viele um Kontrollverlust und ihre Sicherheit bangen.

Zum Thema Sicherheit (im Sinne von Safety) gab und gibt es eine von vielen noch nicht beantwortete ethische Frage: Darf man per Software entscheiden, wer bei einem unvermeidlichen Unfall stirbt? Das Szenario geht immer in die Richtung: Ein Fahrzeug fährt autonom, ein Kind rennt auf die Straße. Links ist eine ältere Person, rechts eine Mauer. Geradeaus weiter und das Kind stirbt. Links ausweichen bedeutet den Tod der älteren Person. Ein Manöver nach rechts würde zwar die die beiden Passanten retten, aber die Insassen opfern. Die Robotergesetze funktionieren hier leider nicht. Es gibt verschiedene Vorschläge, von Statistik (wer hat die besten Überlebenschancen) über Philosophisch und ethisch bis zum Zufallsprinzip. Einzig Mercedes hat sich (meines Wissens) bis jetzt klar für den Insassenschutz ausgesprochen und opfert schwächere Verkehrsteilnehmer. Würde sich auch schlecht im Kleingedruckten einer Broschüre lesen: „In Ausnahmesituationen kann die Software unseres autonomous drive Ihren Tod herbeiführen, um das Leben anderer Verkehrsteilnehmer zu schützen“.

Der wahrscheinlich einzige Schritt, autonomes Fahren möglichst sicher und effizient zu machen, wäre den Menschen komplett aus dem Verkehrsgeschehen herauszunehmen. Würden Computer alle unsere Fahrzeuge lenken, könnten sie sich durch Vernetzung und Determinismus vermutlich zu einem perfekten Fortbewegungsmittel entwickeln. Vielleicht. Wenn wir es wollen.

Sichere Verbindung

Ich hab mir schon länger überlegt, ein Zertifikat zuzulegen. Aber egal ob extern zugekauft oder selbst-signiert, es hätte monatlich auffallend gekostet, u. a. weil mein Hoster eine eigene IP zuweist. Schlussendlich hielt ich es dann doch für weniger notwendig, verschlüsselte Verbindungen anzubieten, da hier – vielleicht etwas naiv gesprochen – eher weniger schützenswerte Informationen gibt.

Nun hat Hetzner eine Partnerschaft mit einem bekannten Antiviren-Software-Hersteller abgeschlossen und bietet zumindest für ein Jahr kostenlose Verschlüsselung für jeden an. Nach der Antwort meiner Rückfrage nach versteckten Kosten habe ich gleich das Zertifikat beantragt. Zwar kam beim ersten Versuch eine Fehlermeldung, aber

Finde ich richtig klasse und hoffe, dass das Angebot in der Form beibehalten wird!

Jetzt müssen nur noch ein paar Links zwischen Blog und Wiki angepasst werden, damit man in der jeweiligen Variante bleibt.