Wer hat an der Uhr gedreht

Als „Computerfritze“ erlebt man ja die verrücktesten Dinge.

Heute hat es mich selbst erwischt: PC gestartet und trotz frischem System und m.2-SSD kommt der Kübel nicht in die Gänge. Nicht einmal Strg+Alt+Entf lässt sich verwenden. Dank 8GadgetPack lässt sich zumindest eine CPU-Auslastung und RAM-Belegung sehen, die sich sehen lassen kann: dauerhaft 100 % CPU-Load und 32 GB RAM rappelvoll.

Ok, Windows 10 macht Schnellstartgedöns, also mal einen „sauberen“ Neustart geben. Nix. Der abgesicherte Modus will auch nicht fliegen. Nachdem noch ganz nette Laufwerks-Aktivität gibt, erst einmal die Sekundärdatenträger abgeklemmt, nicht dass doch Crypto/Ransomware einen Weg durchs offene Scheunentor gefunden hat.

Rien ne va plus.

Zum Glück und aufgrund eines ziemlich beschissenen Bugs der Soundkartentreiber meines Mainboards (den Gigabyte bis jetzt nicht zugeben oder zumindest nachstellen wollte/konnte) habe ich eine Windows Togo-Installation. Also externe HDD ran und den Rechner mit altbekanntem F12-Gehämmer gestartet.

Das EFI-Setup öffnet sich und über der Datenträgerauswahl steht eine Fehlermeldung: Settings reset, please check, blabla. Nanu? Ein zweiter Blick und…

…wer hat an der Uhr gedreht?

Dass sich Browser und Software, die (ablaufende) Zertifikate verwenden an falschen Systemdaten stören, ok. Aber doch nicht Windows?!

Datum korrigiert und nach dem Reboot flutscht die Kiste wieder. Kurz konnte ich im Taskmanager noch sehen, wer sich die knapp 32 geschnappt hat: Der Desktopfenster-Manager. Alles klar, danke Microsoft!

Ich habe es jetzt nicht mehr reprovoziert, aber die Uhrzeit war neben dem XMP-Profil das einzige, was ich im EFI-Setup verändert habe…

Also: Falls der PC mal langsam wird oder sich anderweitig komisch verhält: Uhrenvergleich!

Ganz Problemfreie Software?

Einen Nachtrag muss ich zur GPS-Geschichte meiner Canon-Kamera noch machen: der Support hat mir versichert, dass die A-GPS-Daten auch bei der fehlenden Anzeige des Gültigkeitsdauer an das Modul weitergegeben werden. Das wollte ich zunächst nicht so wirklich glauben, aber auch nicht beweisen. Die „Gute“ soll zu bleiben.

Einen Unterschied der beiden Kameras habe ich noch gefunden: Aufgrund von Problemen bei der Akkulaufzeit während Videoaufnahmen gab es mal ein Firmware-Update. Die „gute“ hat es, die andere nicht. Nachgezogen habe ich noch nichts, aber es wäre noch einen Versuch wert – allein um zu sehen, ob das Verhalten konsistent ist und um auszuschließen, dass die Firmware der „guten“ einen Knall hat.

Um das vermeintliche Problem mit den Assist-Daten zu checken, habe ich mehrfach die TTFF (time to first fix), also die Dauer vom Einschalten des Empfängers zum Ermitteln der Position, gestoppt. Mit und ohne A-GPS-Daten. Um verlässliche Ergebnisse zu erhalten, gab es mehrere Messläufe. Zwar unter dem Dachfenster aber mit freiem Blick in den Himmel. Die Scheibe ist nicht metallisiert, hat also nicht allzu viel Dämpfung. Das Tablet braucht an der Stelle (ok, mit genauer Zeit und Hilfsdaten) nur wenige Sekunden für einen Fix.

Die Messung selbst ist etwas nervig – die Kamera schaltet nach 30 Sekunden das Display ab und man sieht nicht mehr, ob ein Fix zustande gekommen ist. Eine Anzeige der Details zum Status des Empfängers hat sich der Hersteller nämlich gänzlich gespart. Das Drücken zu automatisieren habe ich mir gespart. Also blieb nichts anderes übrig als alle 25 Sekunden irgendeine Taste zu drücken. Um gleiche Ausgangsbedingungen zu schaffen wurde vor jeder Messung der Akku entnommen und ungefähr 10 Sekunden gewartet.

Nach längerem Warten war ich zumindest etwas schlauer: ohne Hilfe bis zu 17 Minuten, mit zwischen 4 und 7 Minuten. Aufgrund der nicht sonderlich großen Reihe und den nicht idealen Bedingungen sind die Werte allerdings mit Vorsicht zu genießen. Für verlässliche Messungen müsste das Ganze unter freiem Himmel, bei gutem Wetter und gleichbleibender Satellitenkonstellation durchgeführt werden – mal schauen, ob dafür die nächsten Tage Zeit übrig bleibt.

Auch wenn der TTFF – verglichen mit anderen Empfängern – einigermaßen bescheiden ist, scheint A-GPS zu funktionieren. Mein Anfangsverdacht Nr 2 hat sich also verhärtet: jemand in der Software hat es verkackt. Könnte schlimmer sein, aber schön ist es trotzdem nicht.

Strg+Z

Argh! Am liebsten würde ich jetzt so lange auf Strg+Z hämmern, bis ich die Kamera nicht zerlegt habe. In wieder mal jugendlichem Leichtsinn habe ich den Bildsensor vom Objektiv getrennt und den Reflektor vom Display gerissen. Mann, bin ich dumm!

Denn: Die Kamera lebt! Einzig der fehlende Blitz wird beim Einschalten bemängelt.

SX280_lebt

Es wäre die perfekte Opferkamera geworden, für nichtmal nen Zehner. Könnt ihr euch vorstellen, wie ich mir gerade in den Allerwertesten beiße? Keine Ahnung, warum das Teil vorher nicht komplett einschaltete (Doch, die 6. Stelle der SNR ist eine 4). Irgendein Dösbaddel hat die Flex zur Hintergrundbeleuchtung abgerissen – und ich möchte nicht ausschließen, dass ich dieser welcher war. *seufz*

Naja, zumindest kann man versuchen, das Beste aus der Situation zu machen – zum Beispiel den GNSS-Empfänger weiter erforschen. Es wäre interessant, ob, wann und wie die Almanach-Daten in den Empfänger kommen. Erster Versuch: Einfach mal die alte EED-Datei drauf und gucken was auf dem UART passiert. Kurz: Nix. Ok, vielleicht lädt die Kamera clevererweise nur die Daten, wenn sie auch gültig sind. Also einfach mal das Datum auf irgendwann 2014 (im gültigen Bereich) gesetzt und neu gestartet.

Here we go:

SX280_upload_almanach

Eine halbe Sekunde Upload. Bei einer Byte-Länge (mit Pause) von ca. 95 µs sind das ca. 7 KiB. Also wohl ein Auszug aus der Datei. Näher hab ich es mir noch nicht angeschaut.

Ok, nun ein völlig abstruses Experiment. Versuchen wir doch mal eine aktuelle EED-Datei, heute frisch vom Canon-Server geladen. SD-Karte rein, Datum umgestellt, Neustart. Der Logic Analyzer zeichnet wieder einen Transfer auf und die Kamera zeigt im A-GPS-Screen den Gültigkeitszeitraum richtig an. WTF!?

Canon, ich glaube, wir haben ein Problem! Ein persönliches sogar!

Als „Beweis“ habe ich ein Video gemacht. Die SD-Karte enthält bis auf die Bilder nichts, was GPS-Infos tragen würde. Meine richtige Kamera lädt keine Daten mehr. Sie ist in dieser Hinsicht also kaputt. Keine Ahnung warum, weil abgesehen von diesem Fehler funktioniert Geotagging ohne Probleme.

Jetzt wäre natürlich der Gedankengang nahe, eine Transplantation durchzuführen: Engine aus der Bastelkamera in die „Produktivkamera“. Nein. Nicht, weil ich fürchte, dass die Kamera dann im Einsatz nicht mehr so stabil läuft – ich vermute eher, dass der Flash neben dem Killflag für A-GPS auch Kalibrierdaten für den Autofokus (obwohl es der dumme mit Kontrastgrenze ist), Bildstabilisierung und ähnliche Korrekturdaten (Tote Pixel) der Kamera enthält. Es wäre ziemlich großer Mist, diese zu „verlieren“.

Jetzt muss Canon ran! Garantie ist vorbei, aber das ist ganz offensichtlich ein Fehler, für den ich nichts kann. Ich hätte gerne eine Erklärung!

Und es wäre nicht das erste Mal, dass sich eine PowerShot ohne meine Hilfe verabschiedet. Bei meiner A95 haben sich die Bond-Drähte vom Sensor gelöst und die A2100 bekam Alzheimer und wusste nicht mehr, wie sie hieß. Beide hat Canon auch nach der Garantie- bzw. Gewährleistungszeit kostenlos repariert, nervig ist es aber trotzdem. Die 300D von meinem Vater habe ich selbst wieder in Gang gesetzt. Mit einem Reißnagel. Vier von 6 Kameras sind somit im Eimer, wobei ich die 400D wegen Unzulänglichkeiten in der Software bzw. einem Objektivfehler auch nicht mehr wirklich nutze. Bleibt also nur die aktuell (noch) intakte 600D von meinem Paps. Vielleicht sollte ich doch mal über einen Systemwechsel nachdenken. Schade, denn ich mochte sie eigentlich ganz gern. Bis auf die Akkulaufzeit bei der SX280 im Videomodus und den nicht sauberen 60 fps-Aufnahmen…

Kann das nicht jemand anders machen?

Ich telefoniere gerne übers Festnetz. Vor allem, weil es recht günstig ist. Erst recht, wenn man auch ins Ausland sehr günstig telefonieren kann. Zum Beispiel mit Sipgate oder EinfachVoip. Von ersterem hat meine Mutter einen Account und 10 Euro als Starterli zu Weihnachten (neben den anderen Geschenken natürlich) bekommen, um eine Freundin in Indien anzurufen. Eine halbe Stunde kostet da so viel wie zwei Brezeln.

Ich selbst habe einen Account bei zweitem Anbieter – momentan noch aus Jux, aber falls doch mal ein Anruf ins Ausland sein muss…

Wie auch immer, eines Gemeinsam haben die beiden Accounts: Nomadische Nutzung ja, Mehrfachlogins nein. Wenn ich aber doch mal vom Handy aus anrufen will? Zweitaccount, daheim abmelden und am Handy anmelden? Nein. Zudem ist SIP reichlich unverschlüsselt und auch ansonsten habe ich in fremden WLANs eine halbwegs „sichere“ Verbindung zu meinem Mailserver oder ins WWW.

Zudem ist es auch im praktisch, vom Hotel-Netzwerk keine APKs untergeschoben zu bekommen (ja, das wurde versucht…) und ich will auch in restriktiveren Ländern Google-Dienste nutzen. Kurzum: VPN ist sehr praktisch.

Wenn es nach LG geht: War. Zumindest beim G2 bringt das Update auf das neuere Android 5.0.1 nicht nur ein neues Design, sondern auch regelmäßige Abstürze, wenn man versucht, sich in ein VPN einzuwählen. Das Problem existiert seit über einem Jahr und der Kundensupport sagt sinngemäß: wir wissen nicht, ob und wann der Praktikant, der das sonst immer gemacht hat, wieder da ist. Ihre Anfrage wurde ausgedruckt und dem Aktenvernichter verfüttert.

Ich frage mich ernsthaft und ein wenig rhetorisch, wie denn die Hersteller ihre Software überhaupt testen. Nein, nicht noch mehr Frustration. Das eigentliche Problem heißt: kein Vanilla-Android.

So viel zum Problem aber was ist die Lösung? Android ist zum Glück ein offenes System, auch wenn die meisten Hersteller Versuchen, dem einen Riegel vorzuschieben. Bis jetzt in den allermeisten Fällen (zum Glück) erfolglos. Denn offenbar bin ich mit dem Problem nicht allein.

Die ersten Versuche mit dem HTC Pyramid (Sensation) und Pico (Explorer) waren Anfangs mit sehr viel Zittern verbunden, Android kam jeweils nicht auf Anhieb hoch. Was, wenn das mit meinem G2 als „daily driver“ passiert? Ich hab aktuell kein funktionierendes Alternativ-Mobiltelefon (außer das Notfall-Nokia 1110i). Andersrum: Wer nicht wagt, der nicht gewinnt und: solche Fehler sind für mich wie ein Splitter im Kopf. Er tut im Moment nicht weh, aber er ist da – und du weißt es.

Also, Augen zu und durch. Mit dem SRKtool Root + TWRP installiert, den KitKat-Bootloader drauf und danach den dorimanx‘ Kernel installieren. Daumen drücken und mit einem verbleibenden Finger auf Reboot drücken. LG-Logo, PIN-Eingabe, aber auch Erfolg? Zumindest die Kernel-Tools mit sehr feinen Einstellungen melden sich.

Ob VPN auch funktioniert? Werde ich sobald wie möglich probieren. Im nächsten offenen WLAN.

Zu der Frage, ob und wie die Hersteller ihre Geräte und Software (nicht) testen gesellt sich nun die Frage, warum es schlussendlich doch wieder die jemand anders – in diesem Fall die Community – fixen muss?

Fritz!Bug

Ich bin ja bekennender Festznetztelefonierer und zufriedener Fritz!Fon-Nutzer – bis auf den Lautsprecher für’s Klingeln/Freisprechen ist das Telefon auch wirklich spitze. Ein paar Ecken und Kanten hat jedes Gerät, heute habe ich eine neue entdeckt und kann sie auch reproduzieren:

fritzfon_bug

Das Gespräch mit der Gegenstelle ist beendet, trotzdem wird das „Geisterbild“ auf dem Display angezeigt, quasi beliebig lange. Ratet einfach mal, wie das funktioniert 😉

Ein Tipp ist schon im Foto zu finden.

Update: Wer es selbst probieren oder einfach nur wissen will: bei internen Rufen muss man, wen die Gegenstelle auflegt beim FritzFon selbst nicht auflegen. Telefoniert man eine Weile, geht ja bekanntlich das Display aus – wenn nach dieser Zeit die Gegenstelle auflegt, passiert am FritzFon (bis auf dem Trennen der Verbindung) nichts. Legt man es nun zurück in die Ladeschale, tritt der oben beschriebene Effekt auf. Kein häufiger Use Case, aber es kann passieren…