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.

ExifTool

Ich mag ExifTool. Obwohl es in der Bedienung für normale Klicki-Bunti-Nutzer schnell komplex werden mag, es ist dennoch ein sehr praktischer Helfer.

Vergessen, im Urlaub die Zeit der Kamera umzustellen? Exiftool ändert im Handumdrehen die Zeitstempel. Die folgende Zeile dürfte für Sri Lanka gelten:

exiftool -overwrite_original -r -DateTimeOriginal+=“0:0:0 3:30:00″ -CreateDate+=“0:0:0 3:30:00″ -timezone=+05:30 ./*

Aber Vorsicht: die Zeile überschreibt alle originale im aktuellen Verzeichnis!
Vorher besser ein Backup anlegen und an wegkopierten Dateien probieren.
In dieser Hinsicht noch ein heißer Tipp, vor allem wenn man mit mehreren Kameras unterwegs ist: Eine Uhr fotografieren! Mit diesem Trick habe ich innerhalb weniger Minuten Fotos von 10 Kameras synchronisiert, die vorher alle unterschiedlich eingestellt waren. Am besten ist natürlich die Uhr eines GPS-Empfängers, dann ist die Zeitnahme natürlich am genauesten.

Ein anderer Spaß, der viele zum (naja, eher weniger) erstaunen bringt: Viele Kameras haben Temperaturfühler eingebaut (vermutlich auch für die Rauschunterdrückung). Ok, es ist schon sehr speziell bis nerdig, beim Fotoabend den Temperaturplot rauszukramen, aber who cares.

Eine andere Anwendung ist, dem Hersteller einen Garantiefall zu beweisen, wenn die Garantie schon vorbei ist. Bei meiner Aanon PowerShot A2100 IR habe ich das zwar noch mit PHP gemacht, mit exiftool wäre das aber auch ein Klacks gewesen.

Mein heutiger Befehl lautet:

D:\Fotos\sx280>exiftool -GPS* -csv -recurse ./ > gps.txt

Er rödelt eine Weile, aber nach ein paar Minuten hat er 14022 Dateien gescannt. Vielleicht ist ja was verräterisches dabei, damit der Defekt des A-GPS innerhalb der Garantiezeit nachgewiesen werden kann ;-).

Ich hatte zumindest schon eine erste Antwort vom Support, die auch gleich mal im Spamfilter landete. Leider ohne Benachrichtigung, dass sie da gelandet ist. Mal schauen.

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…

The strangest deal

Gestern war es mal wieder so weit. Friedrichshafen ruft!

Dieses Jahr war die HAM Radio gefühlt wieder besser besucht, obwohl das Wetter nicht ganz so stabil war wie die Jahre zuvor.

An ein paar Ständen gab es wie auch die Jahre zuvor kaputte Digiknipsen. Darunter auch „meine“ Canon SX280. 15 Euro für eine kaputte Kamera? Ein Argument zum Handeln gab es: der Blitz fehlte. Also den Händler anquatschen und 10 Euro geboten. „Aber da fehlt der Blitz!“ – „ok, dann 8 Euro“. Gut, wenn er meint, dann bekommt er halt nochmal 2 Euro weniger als ich ihm eigentlich geben wollte.

Warum ich sie wollte? Zum einen bietet Canon keine Almanachdaten mehr an, zumindest keine aktuellen mehr. Wenn ich weiß, welcher Chipsatz verbaut ist, lässt sich vielleicht eher etwas finden. Zudem hat das Objektiv zwar eine Delle, scheint ansonsten aber noch intakt zu sein. Immerhin hat es Kleinbild-Äquivalent verrückte 28-500 mm Brennweite. Die Blende ist dann zwar ziemlich zu und die Abbildung nicht mehr ganz so perfekt, aber für den angepeilten Verwendungszweck an der Raspberry Pi-Cam, who cares? Ich hatte schon ein Canon EF-Objektiv am Pi. aus 200 mm Brennweite werden knapp 3000 mm KB-Äquivalent. Den Mond muss man damit ziemlich feinfühlig ansteuern und trotzdem haut er recht schnell ab. Leider ist das Objektiv bei offener Blende nicht ganz so knackig, zum Schließen selbiger braucht’s allerdings zusätzliche Hard- und Software…

Aber ich schweife ab. Don’t turn it on, take it apart? Naja, vorher möchte ich zumindest sehen, was die Kamera noch macht, schließlich habe ich alle Betriebsmittel daheim. Resultat: Der Bildschirm bleibt dunkel, das Objektiv fährt nur kurz aus, dann ist wieder Stille. Aber immerhin tut sich etwas.

Also, auf den Apparat! Alle Schrauben gelöst, braucht man nur noch sanfte Gewalt um die Gehäusehälften voneinander zu trennen. Die Innereien sind erstaunlich aufgeräumt – GPS und WLAN sind erwartungsgemäß Module, wodurch der kleine Schwester SX270 einfach die beiden Platinchen mit Funk fehlen.

SX280_module

Funkmodule der Canon SX280, links: WLAN, rechts: GPS

Auf dem WLAN-Modul ist WYSBCVCXA eingraviert. Eine kurze Suche ergibt: Es ist ein Modul von Taiyo Yuden – nicht die ganze Leiterkarte sondern nur das kleine Teil mit Blechdeckel. Alles außenrum stammt augenscheinlich von Canon, zumindest deutet der Aufkleber auf der Rückseite darauf hin. Im inneren werkelt ein Marvell 88W8787, der mit dem Prozessor über SDIO kommuniziert. Bluetooth und 2,4G-WLAN kann grundsätzlich über die die gleiche Antenne arbeiten, auch scheint das Modul die entsprechenden Bauteile für den Betrieb zu besitzen. Müsste ich nur noch die Anschlussbelegung herausfinden, dann wäre das tatsächlich etwas für den Raspberry Pi. Noch ein kurzer Ausflug: Warum macht man ein Modul auf ein Modul und nicht zumindest den Funkchip direkt auf das eigene Modul? Ganz einfach, und manche kennen es vielleicht schon von den ESP8266-Modulen: Zertifizierung. So muss nur das eigentliche Funkmodul durch die vollständige Zerti. Die Antenne und das andere Außenrum muss man zwar trotzdem noch checken, aber das geht bedeutend schneller und günstiger.

SX280_gnss

Beim GPS-Modul (oder korrekter: GNSS) sieht es leider nicht ganz so gut aus. Auf dem Shielding steht zwar, dass es ein GYCFDMAXX von Canon sei aber bis auf Typenzulassungen findet man nichts im Netz, die Daten auf der Oberseite kommen rein aus der Produktion und das Shielding herunternehmen gefährdet die Elektronik darunter. Nebenbei: wen die Kerben an der Patchantenne irritieren – das war nicht ich mit dem abgerutschten Schraubendreher – das muss so! So werden die Antennchen bei der Produktion getrimmt.

Also keinerlei Infos. Ublox, Broadcomm, Sirf, SkyTraq, Qualcomm, Mediatek oder noch was exotischeres? Keine Ahnung. Da ist mehr Detektivarbeit vonnöten. Im Foto oben sieht man noch leicht die Flex vom Modul – die zwei linken Leiterbahnen sind etwas dicker – das MUSS die Stromversorgung sein. Ich definiere links einfach mal zu Pin 1. Nachdem Pin 2 auf die große Fläche geht, müsste das die Masse sein. Pin 1 ist also die Versorgung. Beim Rest bleibt die Ahnungslosigkeit. Klassischerweise sprechen GNSS-Chips UART oder I²C. Manche auch USB, was aber eher für PC-Empfänger und R&D-Zwecke verwendet wird. Jedes Interface benötigt aber lediglich zwei Leitungen, das Modul ist allerdings mit 8 angebunden. Bei UART kann noch RTS und CTS dazukommen. Was ich mir noch vorstellen könnte wären ein Enable, Interrupt, 32 kHz-Takt oder ein 1-Pulse-per-Second-Signal.

Es hilft nix, da muss ein Messgerät ran – Ich hab da mal was vorbereitet:

SX280_engine

Hab ich erwähnt, wie aufgeräumt das Design in der Kamera ist? Zu meinem weiteren Erstaunen ist die kleinste Bauteilgröße 0402. Ich hätte erwartet, dass Canon im Jahr 2013 schon alles mit 0201 zupflastert. Schön für Bastler, da ist das Umbauen deutlich angenehmer.

Folgende Bauteile sitzen auf der Leiterkarte:

  • Elpida B2064B3PB-8D-F – RAM
  • Macronix MX29GL256FHX01 – Flashspeicher (kein eMMC)
  • Analog Devices ADV7528 – HDMI-Transmitter
  • Renesas (?) R2A30447 – Motortreiber (?)
  • 4957 323A – ???

Vom eigentlichen Prozessor sieht man nichts. Er ist unter dem RAM versteckt – Stichwort Package-on-Package. Zum R2A30447 konnte ich nichts eindeutiges finden, aber Bauteile mit ähnlichen Bezeichnungen sind alles Motortreiber. Zudem deuten die dickeren Widerstände, größere Kupferflächen (um die Wärme wegzubekommen) und die Nähe zum Objektivkonnektor sehr explizit darauf hin. Neben dem Motor für das Objektiv und den Blitz könnte der Chip auch die Aktuatoren für Blende und Voicecoils für den Autofokus und Bildstabilisator ansteuern. Was der Chip mit der Gravur 4957 323A macht, konnte ich nicht herausfinden. Ich vermute, dass es ein IMU, also Accelerometer und Gyroskop ist. Accelerometer, um die Orientierung der Kamera (zum automatischen Drehen der Bilder, was Canon noch immer nicht „richtig“ in den Exif-Daten ablegt) und als Komponente für den Bildstabilisator verwendet. Was noch auffällt: Links unten im Bild befindet sich ein Footprint für einen unbestückten Konnektor. Hmmmm, könnte das vielleicht der Debug sein? 🙂

Zurück zum GNSS – Solderporn gefällig?

SX280_gnss_conn

Eigentlich gar nicht so spekakulär – wie gesagt: die Widerstände sind im 0402-Package. Pin 1, die mutmaßliche Versorgung ist hier rechts. Im letzten Bild sieht man: an ihm hängt auch das Oszi. Pin 4 konnte ich nicht richtig anlöten, weil es anscheinend auf keinen Widerstand unten führt. Vielleicht der in der zweiten Reihe? keine Ahnung. auf jeden Fall kommt jeder Pin an den Logicanalyzer.

Sobald die Kamera Strom bekommt regt sich auch etwas:

SX280_gnss_LA1

Kanal 4 und 5 sieht sehr interessant aus und der Screenshot oben ist schon verräterischer als ich beabsichtigte:

SX280_gnss_LA2

We got signal! UART 115200 Baud, 8N1. Die Signale auf Kanal 5 sind offensichtlich Glitches durch Nebensprechen.

Der GNSS-Receiver meldet:

$PMTK011 MTKGPS*08\r\n$PMTK010 001*2E\r\n

$PMTK010 002*2D\r\n

Wir haben es mit sehr großer Wahrscheinlichkeit mit MediaTek zu tun, der NMEA 0183 spricht. So weit, so gut.

Auf der Suche nach Mediatek und Almanac bin ich auf eine Seite von Gizmochina gestoßen. Darauf ein Link auf http://ftp.epo.mediatek.com. Allerdings ist der Server offline. Aber zumindest gibt es eine Fährte. Auf der Suche nach Mediatek und epo fand ich die Sourcen eines Updaters für Android. Man muss etwas wühlen, aber schlussendlich läuft es auf folgende Ressource hinaus: http://epodownload.mediatek.com/EPO.DAT. Datei heruntergeladen, und neben die aktuelle CAGM01.EED der Kamera gelegt (Die Datei befindet sich auf der Speicherkarte im Ordner \DCIM\CANONMSC\GPS\)  – zumindest die Dateigröße ist gleich. BeyondCompare sagt: Inhalt ebenfalls identisch. Ich habe ein Bingo!

Ok, im Nachhinein hätte ich das auch einfacher haben können. Denn, meine Fritzbox kann Netzwerkverkehr mitschneiden. Der Vollständigkeit halber habe ich das nun auch nachgeholt.

Kurz und knapp baut die Kamera auch eine Verbindung und sendet folgenden Header:

GET /rmds/ic/agps/cagm01.eed HTTP/1.1

HOST: gdlp01.c-wss.com:80

CONNECTION: close

Funktioniert auch im Browser. Als Antwort kommt, wie erwartet, die Datei von oben. Nur zeigt die Kamera noch immer „Gültigk.zeitr. d. A-GPS-Dat.: –.–‚– – –.–.‘–“ an. (warum eigentlich so stark abgekürzt, da wäre noch elendig viel Platz auf dem Bildschirm…)

Vielleicht funktioniert auch nur die Anzeige des Gültigkeitszeitraum nicht?! Naja, zumindest der TTFF liegt irgendwo bei 2 Minuten – ich bin mir also nicht sicher.

In den Untiefen meiner Festplatte konnte ich ältere Versionen der Datei finden. Mit richtiger Dateizeit. Hmmm – was macht wohl die Kamera damit? Also eine von 2014 kopiert, die Karte in die Kamera gelegt und siehe da: ich habe für den damaligen Zeitraum A-GPS-Support. Was passiert nun, wenn ich aktualisiere? Die Kamera behauptet was zu laden, nach dem Update steht aber der alte Zeitraum auf dem Display. Zurück am PC: Ja, die Datei wurde nicht überschrieben.

Bleibt eine Frage: Warum? Drei Ideen hätte ich:

  • Canon hat nur eine zeitlich begrenzte Lizenz von Mediatek oder deren Zulieferern für die Daten (Die Datei wird für andere Produkte auf dem Server aktualisiert oder wurde schlichtweg vergessen)
  • Jemand in der Software-Entwicklung hat es verkackt
  • Canon will, dass eine neue Kamera mit integriertem GPS-Empfänger (die es nicht gibt) gekauft wird

Für den zweiten Fall könnte man sich vertrauensvoll an den Support wenden. So motiviert wie ich sämtliche Consumer-Produkte-Hersteller mittlerweile kennengelernt habe, wird ein Standardschreiben zurückkommen: „Wir haben das Problem weitergeleitet. Ob und wann eine Fehlerkorrektur zur Verfügung steht, können wir zum aktuellen Zeitpunkt allerdings nicht sagen“. Wenn die Person, die diesen Textbaustein geschrieben hat, je Verwendung einen Cent bekommen hätte – sie oder er wären reich. Sehr sogar. 🙁

Und nun: sorry für die Länglichkeit. Wer hat es bis hier geschafft? Schreibt einfach einen kurzen Kommentar!

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?

+4900 +43000

Heute war ich etwas erstaunt und irritiert zugleich: auf meinem Handy ist ein Anruf von der Nummer +4900 und kurz danach von +43000 eingetrudelt. Nachdem ich nicht angenommen habe, kam eine Anruf-in-Abwesenheit-SMS für die Nummer „+“ bzw. „+4917600000000“.

Etwas irritierend. Beim dritten Anruf habe ich selbigen angenommen – was soll schon groß passieren (als angerufener im Inland sollte eigentlich nicht viel passieren, für alles andere gibt es die Bundesnetzagentur)? Wie dem auch sei – es war einfach nur ein Bekannter, der über Skype angerufen und keine Inbound-Nummer hat.

Vermutlich hat für diesen Fall jemand bei der Telefon-Server-Konfiguration geschludert, normalerweise sollte da ein Unbekannt/Unterdrückt kommen (was lustigerweise bei ISDN der Fall ist, was bei VoIP passiert, werde ich die nächsten Tage herausfinden).

Warum ich über so eine Lappalie schreibe? Weil ich dazu keine Infos im Netz finden konnte.

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…

20000 Pixel

Ich bin ja so ein idiot, der Software kauft. Da ärgert man sich dann ein wenig, wenn etwas nicht so funktioniert, wie man will. So gesehen bei Corel Paintshop Pro X5. Dort halten es die Entwickler nicht für notwendig, dass man Bilder auf Kantenlängen größer als 20000 Pixel skalieren (sprich Größe ändern) kann. Dagegen kann man deutlich größere Bilder öffnen und problemlos anderweitig bearbeiten.

Der Support von Corel (wenn er nicht gerade die Bearbeitung der Anfrage verweigert), sagt dazu folgendes:

Sehr geehrter Herr Christof Rueß,

Vielen Dank für Ihr Kontakt mit Corel Kundendienst.

Die Funktion zum Ändern der Bildgröße ist leider auf 20000 Pixel begrenzt.
Sie können das nicht ändern. So ist das Programm entwickelt.

Ich wette, mit einem Disassembler könnte ich das ändern. Außerdem habe ich nicht gefragt, ob ich das ändern könnte, sondern gemeldet, dass das ein Problem sei.

So werden also Bugs behandelt. „Ich sehe sie nicht, also sind sie nicht da“.

Danke Corel! (auch übrigens dafür, dass der HDR-Renderer beim Öffnen von Dateien reproduzierbar abstürzt)

USB != USB

Bei einem Nicht-hobbyelektronik.org-Projekt habe ich mit einem Mikrocontroller mit USB-Controller zu tun.

Nachdem das Projekt pausiert war, wollte ich mich nun wieder damit beschäftigen. Da meine beiden Monitore USB-Hubs haben und diese auch mit dem PC verbunden sind, war naheliegend, das Device auch daran zu betreiben. Mit unveränderter Firmware und (nur nach Visual Studio 2010) konvertierten Software tickte das Teil ohne Probleme – zumindest einige Sekunden. Zunächst habe ich ein Timing-Problem vermutet, da ich die Hardware mit knapp 50Hz gepollt wird und die Firmware noch nicht optimiert ist, dem war aber nicht so. Auch mit 10Hz und weniger blieb die Verbindung stehen. Die C#-Software blieb beim Schreiben auf das Device einfach stehen, genauso lief die Firmware (außer Interrupt-Behandlungen).

Was ist da los? Die Ursache ist sehr einfach: Der Monitor ist schuld. Anscheinend ist der USB-Hub in meinem NEC LCD2170NX nicht so ganz standardkonform. Zumindest war dieser für die Ausfälle verantwortlich. Am Hub der deutlich billigeren FSC-Möhre (die etwas aktueller ist) funktioniert das Teil tadellos.

Genauso wollen Bus-powered Festplatten an manchen USB-Kabeln einfach nicht funktionieren (vermutlich zu großer Innenwiderstand in den Versorgungsleitungen).

Sowas muss man einfach wissen oder zumindest einmal darauf reinfallen.

Aanon PowerShot A2100 IR

So, bin wieder aus China zurück, war sehr spannend – ich habe zwar auch einen Artikel für hier geschrieben, werde ihn aber erst die nächsten Tage erst veröffentlichen – falls mir noch etwas einfällt 😉

Wie dem auch sei, beim ersten Durchsehen meiner Bilder ist mir etwas merkwürdiges in den Exif-Informationen meiner Kamera aufgefallen:

Da hat der Kamerahersteller und der Modellname etwas gelitten. Zumindest wäre mir nicht bekannt, dass es eine kompakte Infrarotkamera gibt (war mal IS).

Das würde auch erklären, warum die Kamera seit geraumer Zeit keine mit ihr erstellten Videos mehr erkennt…

Da es mich interessiert hat, habe ich ein kleines Script geschrieben, das von alle mit der Kamera aufgenommenen Bilder die Exif-Informationen ausliest und diese bei Veränderung vom Manufacturer- oder Model-Feld einen kleinen Dump ausgibt. Zusätzlich sucht das Script das erste Vorkommen der Manufacturer/Model-Kombination:

[Make] => Canon
[Model] => Canon PowerShot A2100 IS
[DateTimeOriginal] => 2010:09:18 18:31:16
[ImageNumber] => 1001171
[OwnerName] => sion 1.00
[FirmwareVersion] => IS JPEG

[Make] => Canon
[Model] => CanoN PowerShot A2100 IS
[DateTimeOriginal] => 2011:04:24 11:40:54
[ImageNumber] => 1170699
[OwnerName] => sion 1.00
[FirmwareVersion] => IS JPEG

[Make] => Aanon
[Model] => CanoN PowerShot A2100 IR
[DateTimeOriginal] => 2012:04:16 17:41:22
[ImageNumber] => –
[OwnerName] => –
[FirmwareVersion] => –

Erstaunlich – da sind nacheinander die Bits in der Firmware weggekippt. Genauere Untersuchungen stehen noch au, aber da ist auf jeden Fall etwas nicht in Ordnung.Ich bin nur froh, dass meine Bilder von China inhaltlich unbeschadet sind, ansonsten wäre es mehr als ärgerlich gewesen.

Mit dem Canon-Support habe ich zwar schon telefoniert, aber von dort heißt es lediglich, dass die Kamera repariert werden muss. Frage ist nun: war der Fehler von Anfang an – und wenn ja: muss Canon die Reparaturkosten übernehmen? Das kann bezüglich der Beweislastumkehr durchaus spannend werden. Evtl. geht da aber was über Kulanz…