Zweiundvierzig

Jeder kennt sie, viele hassen sie – „Sicherheitsfragen“. Eine solche sollte ich heute beim Besuch des Kundencenters der Telekom einrichten.

Die Frage selbst kann man in aller Regel nicht frei wählen, die Antworten dieser Fragen lassen sich oft durch Social Engineering erarbeiten.

Aber die Telekom hat auch eine Frage im Katalog, deren Antwort eigentlich schon vor-ausgefüllt sein könnte:

Sicherheitsfrage „Wie lautet die Antwort auf die Frage aller Fragen?“

Ich frage mich tatsächlich und ehrlich, wie oft hier „Zweiundvierzig“ eingegeben wird (und ob die Eingabe zulässig ist). Liest hier jemand von der Telekom mit, der zugriff hat und mal eine Statistik rauslassen könnte?

Allgemein ist Passwortsicherheit ein Thema für sich. Viele IT-Abteilungen erfordern fordern z. B. einen sehr engen Wechselzyklus und Anforderungen wie Groß- & Kleinschreibung, Zahlen, Sonderzeichen, ein kyrillisches Zeichen, zwei Hiragana-Zeichen, eine persische Zahl und ein Emoji. Grund: weil es sicherer ist.

Ich bin eher der Meinung, dass es ziemlich großer Unsinn ist. Passwortüberprüfungen erfolgen nicht nach dem Prinzip des Spiels Mastermind. Es gibt entweder ein true oder ein false und nicht, ob und wie viele Zeichen richtig sind. Zudem lässt ein häufiger Passwortwechsel die Leute unkreativ werden. Dann gibt es Stammpasswörter mit einer Variablen wie das Datum des Passwortwechsels oder es steigt ganz einfach die Gefahr, dass das Passwort irgendwo notiert wird. An der Stelle möchte ich nicht wissen, von wie vielen das Passwort nicht nur unter der Tastatur klebt, sondern gleich Cherry oder Logitech verwendet wurde.

Auch habe ich schon viel zu oft gehört und gelesen, dass man als Passwort die ersten Buchstaben eines Satzes verwenden und noch eine Leetspeak-Zahl und ein Sonderzeichen reinnehmen soll. Beispiel: Das ist das Haus vom Nikolaus: DidHvN, mit Zahl dann D1dHvN. Mit dem erstbesten gefundenen Passwort-Crack-Estimater liegt das erste Passwort bei 6 Sekunden, das zweite bei 20 Sekunden. Würde man den kompletten Satz als Passwort nehmen, läge man bei 7,2*10^38 Jahren. Wie gesagt, unter der Annahme, dass die Passwortprüfung nur ein true/false zurückgibt. Ein kompletter Satz ist beim „Shouldersurfing“ vermutlich nicht ganz so gut, da man es in diesem Fall etwas einfacher als scheinbar zufällige Tastendrücke rekonstruieren kann – aber: das ist zusätzliche Information. Da der Aufwand bei Bruteforce-Attacken mit der Länge des Passworts exponentiell steigt, ist es von Nachteil, kurze, komplexe Passwörter zu verwenden.

Aber solche Angriffe sind mittlerweile eh langweilig – spätestens nach dem 10. Fehlversuch dürfte/sollte jedes Formular für eine Weile dicht machen. Kritischer ist heute nicht mehr das Passwort selbst, sondern die Person, die es eingibt.

Ein Passwort für alle Dienste, ungesichert gespeicherte Passwörter im Browser und ganz vorneweg: Zeug anklicken. Das Konto muss verifiziert werden? Klick. Unaufgeforderte Passwortwiederherstellung? Klick. Irgendwas gewonnen und man muss sich mit den Credentials der Seite einloggen, auf der die Werbung stand? Die Liste der Möglichkeiten ist lang.

Meine Strategie: Lallo-Passwörter liegen im (gesicherten) Passwortmanager, die wichtigeren (bei denen etwas bei einem Leak kaputt gehen könnte) existieren nur im Kopf. Dazu noch 2FA wo es möglich und sinnvoll ist. Zudem genau schauen, wo man denn nun sein Passwort eingibt.

Hier schlägt auch der Vorteil eines Passwortmanagers, der im Browser integriert ist, zu: Der schlägt den einzugebenden Login erst einmal nur auf den legitimen Domains vor, was schon sehr hilfreich sein kann.

Bei der Sicherheitsfrage von der Telekom habe ich übrigens einen zufällig generierten Text eingetragen, auch wenn DIE ANTWORT aller Fragen verlockend gewesen wäre. Wobei der Kenner weiß: Es ist nicht die Antwort, es ist die Frage.

Homeoffice oder: der dumme USB Sharing Switch

Seit Mitte März arbeite ich nun durchgehend zu Hause.

Damit es keine Doppelbelegung gibt und auch der Laborplatz verwendet werden kann, hängt das Arbeitsnotebook an meiner restlichen Peripherie. Die ersten Tage bin ich jeden Tag noch zweimal unter den Tisch, um die DisplayPort-Stecker von PC zu Notebook und wieder zurückzustecken. Recht schnell kam dabei der Gedanke: für wie viele Zyklen sind die Konnektoren überhaupt gemacht?

Leider hat das Dock vom Arbeitsgerät nur VGA (für 1440p eine Zumutung) und 2x DP. Aber: das Notebook selbst hat zumindest einen HDMI und meine Bildschirme jeweils auch. Mein uraltes Thinkpad hatte doch auch (nur) Displayport und alles, woran man es damals anschließen wollte, hatte wenn dann nur HDMI – also kam mal ein Adapter ins Haus.

Nun muss nur noch, Maus, Tastatur, Mikrofon und Kamera umgesteckt werden. Um nicht alles einzeln zu machen hängen alle Geräte an einem USB-Hub. Auch wenn es jetzt deutlich bequemer ist, unter den Tisch muss man trotzdem noch.

Aber auch das Problem lässt sich lösen. Für eine alte Bastelei hatte ich noch einen USB-Schalter – den auf Umschalter umzubauen, dazu noch mit vernünftigem Power select (keine Rückströme), dürfte ziemlich unangenehm sein. Glücklicherweise gibt es so etwas im Austausch kleine bunte Papierstreifen nach Hause geliefert:

USB-Umschalter „Auto Sharing Switch“

2 Buchsen für den PC, eine (verbogene) für ein Gerät, zwei Tasten. Einfach wie effektiv. Bei den Kosten und aus reiner Neugierde kann man schon einmal einen Blick ins Innere werfen. Zunächst die Unterseite:

Leiterkarte des USB-Umschalters von unten

Hmm, mit lecker Kruste sowie Hotfix (rechts oben) und ein bisschen Lötzinn an der USB-Buchse als Beilage. Das kann oben nur besser werden…

Oberseite des USB-Umschalters

Ok, das Teil heißt also FJ-U02S und stammt von www.fj-gear.com und sieht soweit gar nicht mal so gut aus – man beachte den Bereich rechts unten – da ist wohl mal der Schraubendreher (oder Hammer?) ausgerutscht…

Noch einmal ein bisschen näher:

Was um alles in der Welt haben die in der Fabrik mit dem Teil angestellt? Es fehlen Pads von 5 Bauteilen und der Hotfix macht es auch nicht besser… Die beiden Widerstände sind übrigens 1k. Der C war warscheinlich ein kläglicher Versuch, noch irgendwas am Ausgang zu filtern. Der kann von mir aus weg bleiben. Trotzdem habe ich es mir nicht nehmen lassen, die Leitungen noch ein bisschen zu verstärken.

Der Transistor schaltet übrigens die Versorgung des angeschlossenen Devices – auch dank der Dioden in Reihe mit VBUS von den Hosts ist es nicht ratsam, ein Gerät das sich über USB versorgt anzuschließen – zumindest ohne aktivem USB-Hub. Ohne Last habe ich am Ausgang knapp 4,3 V gemessen (obwohl es nach Marking Schottky-Dioden sein sollten).

Ansonsten finden sich folgende Hauptkomponenten auf dem Board:

  • WCH CH440G – Analog-Switch (PDF-Link nach China)
  • WCH CH9882 – Vermutlich ein Mikrocontroller mit USB
  • OnSemi NC7SZ32 – TinyLogic OR-Gate
  • NXP 74HC123D – Dual retriggerable monostable multivibrator with reset
  • ST LM358 – Operationsverstärker

Warum das Teil einen Mikrocontroller hat? Vermutlich aus dem gleichen Grund, warum eine CD beiliegt: Damit man vom (nicht verbundenen) PC aus den Host umschalten kann. Ich war so mutig/dumm und habe die Software installiert – allerdings tut sich soweit gar nichts.

Das Gerät meldet sich mit VID 0x1A86 und PID 0xE040 als HID an und hat sonst keinerlei Beschreibungen. Laut HID-Descriptor hat es eine Reportlänge (in und out) von 9 Byte (inkl. Report ID). Wer sich für mehr interessiert, hier mal der komplette Dump aus USB Device Tree Viewer

Leider ist das Teil nicht intelligent genug, auf den Host umzuschalten, der gerade aktiv ist (wenn der andere aus ist). Damit könnte das Teil einfach unsichtbar unterm Schreibtisch verschwinden.

Unterm Strich sieht mein Setup nun ungefähr wie folgt aus:

Einzig der (powered) USB-Hub muss manchmal aus- und wieder eingeschaltet werden, wenn die Einschaltreihenfolge der Stromversorgung und PC nicht passt. Aber vielleicht findet sich dafür auch eine sinnvolle Lösung 🙂

Beim Schreiben des Beitrags ist mir übrigens aufgefallen, dass Video auch gänzlich übers Dock funktionieren dürfte, da die Grafikkarte am PC auch einen HDMI hat. Also: 1x DP und 1x HDMI jeweils vom PC & Notebook. Solange ich aber nicht spontan zwischen Homeoffice und Arbeitsplatz wechsle bleibt es erst einmal so wie es ist.

15 Jahre

Wenn die Chronik nicht lügt, gibt es hobbyelektronik.org nun seit 15 Jahren. Wie doch die Zeit vergeht.

Zum Geburtstag gibt es deshalb auch eine kleine Neuerung: Das Wiki ist jetzt wieder auf einer aktuelleren Version und hat auch einen neuen Anstrich bekommen. Auf großen Bildschirmen nimmt es nun zwar nicht mehr die gesamte Breite ein, dafür passt es nun auf kleinen Bildschirmen besser. Insgesamt sollte die Lesbarkeit nun verbessert sein.

Ein netter Nebeneffekt ist, dass die Seite (gefühlt) etwas schneller reagiert.

Fehlt etwas oder ist was kaputt? Gefällt es euch nicht? Bitte gebt mir einfach Bescheid 🙂

A-GPS für die Canon SX280

Manchmal muss man alte Beiträge nochmal ausgraben.

Canon hat letztes Jahr angekündigt, ab 1. Januar 2020 keine A-GPS-Daten mehr für die SX280 anzubieten. Diese ermöglichten, einen Cold Start des GNSS-Empfängers auf wenige Sekunden zu verkürzen. Die Meldung ging an mir komplett vorbei, nicht aber Andreas, von dem der Hinweis kam.

Er konnte auch direkt bestätigen, dass auf den Servern von Canon die Datei zwar noch angeboten wir, der Inhalt aber einen Stand vom 05.01.2020 aufweist.

Um es kurz zu machen: Zum Stand meines alten Artikels hat der Download von http://epodownload.mediatek.com/EPO.DAT funktioniert und entsprach der Datei \DCIM\CANONMSC\GPS\CAGM01.EED auf der Speicherkarte der Kamera. Das ist auch heute noch so.

Keine Ahnung, was man mit dieser Information anfangen kann…

Zugegebenermaßen: die olle Knipse verwende ich nicht mehr wirklich, hat sich im Urlaub vor zwei Jahren aber noch ganz passabel als Notfallkamera und vor allem als GPS-Logger bewährt.

GPS-Logging habe ich bisher nicht mit dem Telefon gemacht, da es zumindest früher immer wahnsinnig Akku gesaugt hat – aber auch hier hat Andreas einen Tipp: https://gpslogger.app – ohne, dass ich es bis jetzt getestet habe.

Noch ein weiterer Hinweis von ihm:

[…] scheint täglich um 05:55

(tDiff +6h, dh kurz vor TW-Mitternacht!?) upgedatet zu werden.

Info zur Struktur der Datei gefunden:

https://github.com/mru00/crane_gps_watch/tree/master/snoops

[…]

Noch eine andere Anmerkung (meinerseits) zur Thematik: „It’s all fun and games, until they shut down the servers.“ – Bei enorm vielen neuen Geräten sind Dienste im Internet mehr oder weniger zwingend erforderlich oder ein Teil des Produkts – wie man schon ein paar Mal gesehen hat und in Zukunft noch viel öfter sehen wird: irgendwann ist das Zeug zu legacy oder schlicht und ergreifend die Firma hinter dem Produkt zu Pleite und die Investition ist verloren.

Daher ist meine Meinung: Wenn ein Produkt nicht mehr unterstützt oder gar begraben wird, sollte es oder deren Services an die Community übergegeben werden. Der IP (intellectual property) ist für den Hersteller eh nicht mehr interessant oder zumindest überholt und so kann Landfill und Sicherheitslücken vermieden und die die Kunden bei Laune gehalten werden. Natürlich entspricht das nicht dem Ziel gewinnorientierter Firmen, deswegen sollte hier auch etwas aus der Regierung kommen.

Lageerkennung als MEMS noch teuer war (Part 2)

Weil die Teile der anderen Kamera doch noch herausgekommen sind, so hat es Canon früher bei den EOS gemacht:

Die gezeigte Fläche zeigt nach unten (in Richtung Stativgewinde)

Die beiden Bauteile auf der „Origami FPC“ erwecken schon den Eindruck von Gabellichtschranken. Setzt man den Schraubendreher an, kann man den Deckel öffnen und sieht dann sogleich die Plastikkugel, die je nach Lage den Lichtstrahl unterbricht:

Lageerkennung als MEMS noch teuer war

Durch Zufall ist mir vor kurzem eine ältere kaputte Canon-Kompaktkamera in die Hände gefallen. Eigentlich war ich nur an der Optik interessiert, das Mainboard wanderte aber nicht direkt in die Tonne.

Als ich es heute dann doch mal in die Recycling-Box packen wollte, fiel mir ein Bauteil auf:

Neben Controller, Speicher, Oszillator und weiteren befindet sich ein eher auffälliges Bauteil auf der Leiterkarte

Hoch und Keramikdeckel. So ähnlich sahen auch schon die früheren Beschleunigungssensoren aus Thinkpads aus. Unter dem Aufdruck „1453K“ bzw. „35184“ ließ sich nichts im Netz finden. Da der Deckel etwas übersteht, warum nicht mal daran knibbeln?

Das war etwas unerwartet. Der kleine Metallpuck lässt sich frei bewegen und obwohl er sehr nach Neodym-Magnet aussieht, ist er nicht einmal ferromagnetisch. Die Scheibe oben ist von innen mit Gold beschichtet, der Grundkörper hat 3 Löcher. Bei genauerem Blick entpuppen sich diese als…

…etwas optisches!

Durch etwas mehr Knibbeln lässt sich der Körper entfernen:

Klick macht wie immer groß

Meine beste Vermutung ist: oben eine (IR-)LED, links und rechts Fotodioden. Der Deckel dürfte ein ziemlich guter Reflektor sein. Je nachdem, wo die Metallscheibe liegt, lassen sich alle für die Fotografie grundlegend wichtigen Lagen für Portrait und Landscape erkennen, das sogar binär. Rechts im Bild ist Kamera oben, nennen wir den rechten Sensor (oben) mal 1 und den linken (unten) 2, so erhalten wir folgende Zustände:

Sensor 2Sensor 1Lage ScheibeOrientierung
dunkeldunkellinksPortrait (90° )
dunkelhelluntenLandscape (0°)
helldunkelobenLandscape kopfüber (180°)
hellhellrechtsPortrait (270°)

Genial einfach und „damals“ einfach genial. Leider habe ich die Innereien einer alten Canon DSLR schon weggeworfen, dort befanden sich zwei gedeckelte Optokoppler, im 90° Winkel angeordnet, mit zunächst unbekannter Funktion. Beim Schütteln haben sie geklappert, beim Öffnen kam jeweils eine kleine Plastikkugel entgegen. Die Mechanik ist vermutlich auch der Grund, warum sich meine olle PowerShot eine Zeit lang entschied, alle Bilder im Portrait darzustellen – vermutlich ist Feuchtigkeit in den Sensor gekommen und hat die Kugel/Scheibe „verklebt“.

In meine aktuelle Kamera (von 2016, wie die meisten anderen) hat mittlerweile einen Beschleunigungssensor und schreibt die Informationen sogar in die Bilder:

Accelerometer Z                 : 132
Accelerometer X                 : -8
Accelerometer Y                 : 213
Camera Orientation              : Tilt Downwards
Roll Angle                      : -3.2
Pitch Angle                     : -58.1

Good boy. Leider fehlen bei der Lumix so Informationen wie Temperatur und intrinsische GPS-Koordinaten (GPS-Tagging per Handy ist Mist).

Wer den Lagesensor noch einmal genauer (allerdings nicht ganz so guter Abbildungsleistung) sehen will, here you go:

Die perfekte USB-I2C-Bridge

TL;DR: Ich habe sie noch nicht gefunden und mich beschleicht das Gefühl, dass ich selbst eine (weitere, nicht perfekte) bauen muss.

Aber erst einmal auf Anfange: Mangels halbwegs flotter Alternative habe ich Libs in Python und C# (ein paar fixes stehen noch aus) um mit dem MCP2221 von Microchip zu sprechen.

Der Chip ist einfach und macht auch ungefähr, was er soll. Nur leider ist er – nicht nur aufgrund der natürlichen Beschränkung von USB HID – verdammt langsam. Speziell wenn es um Standardaufgaben wie Register lesen geht. Das ist ein richtig großer Zeit- und Performancefresser, denn: man muss es „kleinteilig“ durchführen: Register an den Controller schicken ist ein Befehl, auf den geantwortet wird, dann muss man den Lesebefehl senden (auf den auch wieder geantwortet wird) und anschließend muss man für jeden 60-Byte-Chunk der gelesenen Daten auch wieder lesen und auf die Antwort warten. Ich bin mir nicht ganz sicher, ob die Antwort im gleichen oder nächsten USB-Interrupt-Zeitschlitz kommt, aber im dümmsten Fall würde das bei einer ein Chunk großen Leseanforderung 2+2+2 ms bedeuten. Bei 20 Registern (manche Chips lassen das Lesen im Block nicht zu, durchaus aus guten Gründen) wären das 120 ms. Dann war’s das mit 10 Refreshes pro Sekunde – zugleich stottert das UI, wenn man die Kommunikation nicht in einen anderen Thread auslagert. Alles großer Mist. Im Datenblatt sind zudem Fehler u. a. in der Protokollbeschreibung und der einzige Kontakt bei Microchip (immerhin, sie haben geantwortet, was ich nicht erwartet hätte) hat sich hinter seiner NDA versteckt – obwohl die erfragten Infos teilweise schon im (von Microchip geschriebenen) Treiber für Linux stecken.

In der Hoffnung, dass es andere Hersteller besser machen, habe ich mir einen CP2112 von Silicon Labs geholt. Silabs hat einige Dinge deutlich besser gemacht – neben den deutlich höheren Bustakten (> 1 MHz) es gibt einen Befehl (und Konfiguration), der Leseanfragen deutlich verkürzt. Mit aktiviertem „Automatically send read response“ lässt sich ein Register mit n byte Länge am Chip mit Adresse a wählen und die Antwort der Länge l wird ohne weitere WriteReports an den Controller zurückgesendet. Im Schlimmsten Fall dauert der Lesen eines Chunks 2 ms. Beide Baumen Hoch!

Tja, wenn sie nicht in anderen Situationen ziemlich verkackt hätten. Hat man den auto read response an und möchte mit einer I2C-Adresse sprechen, die es auf dem Bus nicht gibt, läuft man ohne Threading in einen Deadlock, da es einfach keine Antwort vom Controller gibt und die ReadReport-Methode blocking ist (auch das Setzen des read timeout und retry count bringt nichts). Gerade beim I2C-Detect ist das ziemlich bescheiden. Richtig bescheiden ist an dieser Stelle auch, dass man keinen „Klingelstreich“ (Start, Adresse auswählen, Stop und einfach nur Auswerten, ob ein oder kein ACK kam) machen kann. Man muss immer mindestens ein Byte lesen. Das kann bei manchen Devices für Ärger sorgen. Gleichzeitig habe ich es nicht geschafft, bei Adresse 0 zu „klingeln“. Obwohl diese, gerade wenn man einen SMBus auf dem Tisch hat, wichtig ist.

Ja, das kann man alles umschiffen, aber wiederum zulasten der Performance. Dabei wäre alles super einfach in der Firmware zu implementieren. Anderes Manko des Chips: Man kann höchstens 512 Byte am Stück lesen und nur 61 (?) Byte am Stück schreiben. Warum nur?

FTDI FT232H (und andere). Kein HID, also muss man sich entweder mit einer DLL von FTDI herumschlagen oder mit LibUSB/WinUSB herumbasteln (Tolle Projekte aber da man Zadig verwenden muss, ist es kein wirkliches Plug & Play mehr. Was mir an der Sache überhaupt nicht gefällt: Obwohl man für das beste Benutzererlebnis die DLL von FTDI benutzten muss, ist es nötig, die MPSSE-Pakete selbst zusammenbasteln. Gleichzeitig gibt es beim Initialisieren anscheinend Glitches auf den Busleitungen und zwischen Start condition, Adressierung und Stop condition habe ich bei ersten Tests wahnsinnig große Zeitlücken gesehen. Ich habe mich nicht wirklich intensiv damit auseinandergesetzt, aber bis jetzt hat mich das elendige Treibergeschwurbel aktiv davon abgehalten, Code dafür zu schreiben.

WCH CH341A: Ein Kit liegt hier und ich habe aus Anwendersicht erste Tests (mit einem EEProm) durchgeführt. Sieht nicht ganz schlecht aus. Wie der FT232H ist es kein USB-HID und man darf wieder mit der bereitgestellten DLL oder anderen Libs basteln. Ein Bastelkollege hat sich der Sache schon angenommen. Großes Problem: Alles aus erster Hand ist nur auf chinesisch. Da ich auf der Website nix lesen kann, ist sie auch nicht verlinkt. Englische Dokus kommen m. W. nur aus der Community. Muss nicht schlecht sein, aber es riecht halt alles ein bisschen arg bastelig.

Von Cypress habe ich mal ein PSoc4-Devkit (so ein Stick) mit Kitprog USB bekommen, der auch sehr schnell I2C sprechen kann. Das Teil hat sich aber durch mehrere Dinge sehr schnell disqualifiziert: Den Treiber gab’s nicht einzeln, eine Doku zum Protokoll glaube ich auch nicht und das Teil hat sich extrem schnell so stark verschluckt, dass man die Hardware neu starten musste.
Es gibt noch z. B. den CY7C65211, allerdings ist mir in freier Wildbahn noch kein Devkit über den Weg gelaufen und ich hatte mit einem anderen USB-Chipsatz schon ein bisschen Probleme, was Treiberstabilität (irgendein USB-UART-Wandler, man konnte den Port öffnen, aber es gingen keine Daten durch). Ein paar haben sich auch ziemlich empfindlich gegenüber Störungen von außen gezeigt. Ob es der Chip oder die externe Beschaltung war, ließ sich nicht mehr richtig rekonstruieren, aber da haben doch ein paar Bauteile dicke Backen gemacht.

Alternativen? Da gäbe es noch den Buspirate von Dangerous Prototypes. Für den Entwickler-Tisch ok, aber für den ganzen Rest einfach zu groß. Zudem bis jetzt keine Single-Chip-Lösung eher ein USB <> UART <> irgendwas-Wandler

Ok, wenn wir schon beim Entwicklertisch sind – Aardvark von TotalPhase. Macht man da einmal den Deckel auf (zumindest den, den ich mal auf dem Tisch hatte), sieht man nix anderes als einen USB <> UART + AVR. Zugleich konnte man ihn nicht standalone verwenden, sondern braucht(e) eigentlich immer den ziemlich klobigen Levelshifter. Die Software ist fummelig und instabil, wobei ich nicht herausgefunden hab, ob es nicht vielleicht auch die Hardware war. Hab das Teil auf jeden Fall sehr schnell wieder zur Seite gelegt. Für meine Begriffe ist das Teil nicht seinen Kosten gerecht.

Was wäre da sonst noch? TI? Die hatten IIRC mal etwas im Programm aber das war entweder ziemlich lausig oder zumindest für Normalsterbliche faktisch nicht verfügbar.

Sonst fällt mir nicht mehr viel ein. Außer, dass ich schon vor längerer Zeit die Idee hatte, selbst einen USB<>irgendwas-Wandler zu bauen. Leider ist es bis jetzt in der Planungs-Featuritis hängen geblieben. Mal grob, was ich mir vorgestellt habe, was es können muss^Wsoll:

  • GPIOs + IRQs, PWM, …
  • ADCs
  • SPI
  • I2C
  • OneWire
  • SMI/MDIO (clause 22/45)
  • UART + RS485

Nachtrag vom 16.12.2019:
Christoph hat mich auf I2C-MP-USB von Thomas Fischl aufmerksam gemacht – vielen Dank für den Hinweis – das Teil landet auf der Bastelliste und wird sobald wie möglich getestet.

Multiscreen unter Windows 10

Mit dem gestern erwähnten Wechsel des ausgedienten alten Bildschirms stehen nun zwei gleich große (hinsichtlich Auflösung und Panelgröße) Pixelschleudern auf dem Schreibtisch.

Was ich am alten Setup und mochte: der kleinere Bildschirm (2) vertikal mittig zum größeren (1) angeordnet. Mit dem Effekt, dass die Cursor in den Ecken des größeren gefangen (primären Bildschirm) wurden, bildlich gesprochen in etwa so:

Das Setup habe ich unter Windows 10 behalten, weil man sehr schnell per Doppelklick in der linken oben Ecke das aktuell maximierte Fenster schließen konnte und links unten war man direkt im Startmenü. Zudem kann man auf die Weise sehr einfach den Cursor „wiederfinden“ wenn er im Wimmelbild untergeht – Cursor erst nach unten, dann nach links – und man muss nur in zwei Ecken suchen (ok, die anderen Ecken gehen natürlich auch)

Mit zwei Bildschirmen mit gleicher Auflösung rutschte man unter Windows 7 beim Verschieben des Cursors auf einem Bildschirm direkt auf den anderen, was dann in etwa so aussieht:

Unter Windows 10 gibt es, neben der sich wiederholenden Taskleiste, einige kleine aber sehr schöne Funktionen für mehrere und vor allem größere Bildschirme:

Der Cursor wird in jedem Fall gefangen, wenn man ihn in die „gemeinsame Ecke“ zweier Bildschirme schiebt. Der Fangradius beträgt gefühlt nur 5 Pixel, aber die machen schon einen angenehmen Unterschied. In etwa so:

Dann wären da noch, dass die Bildschirmflächen beim „Anschnappen“ von Anwendungen als solche berücksichtigt werden. Der Cursor ist hier auf angenehme Weise am Bildschirmrand magnetisch. Bei Windows 7 muss(te) man den Workaround Win+Cursor gehen, um ein Fenster an die linke Seite des rechten Bildschirms zu kleben. Zudem können Fenster nun in den 4 Quadranten eines jeden Bildschirm packen, vielleicht ist bald (auf Umwegen auch jetzt schon mit den Powertoys) auch ein mehrspaltiges Layout möglich.

Ja, es sind kleine Dinge, aber obwohl ich Win10 sehr lange eher kritisch gegenüberstand muss ich sagen, dass viele (auch kleine) Funktionen mittlerweile sehr durchdacht sind. Vor dem nächsten Feature Upgrade werde ich aber trotzdem ein vollständiges Backup machen.

Blickwinkel

Es wurde Zeit für eine neue Schreibtischleuchte.

Mittlerweile haben ja so gut wie alle PC-Monitore nur noch sehr wenig Rand. Der alte hier hatte knapp 2 cm, der neue noch knapp 8 mm. Gleichzeitig ist aus dem TN-Panel ein AH-IPS geworden, das mit einem sehr großen Blickwinkel angegeben ist. Überspitzt tritt heutzutage eher die Totalreflexion ein als dass man auf den Displays aufgrund des Panels nix mehr sieht.

Allerdings – und das habe ich nun bei vielen neueren Bildschirmen beobachtet – reicht das Backlight nicht mehr weit genug über das Panel heraus, um bei flacheren Winkeln noch ein sauber ausgeleuchtetes Bild zu haben:

Aktueller Screenshot von stackoverflow.com

Am Rand wird’s dunkel. Der andere Bildschirm mit satter 2 cm-Kruste hat den Effekt nicht.

Ansonsten bin ich mit dem Teil recht zufrieden. Die Farbtemperatur und -wiedergabe passt auch fast perfekt zum anderen Monitor, nur gibt es einen Bug beim Asus BE27A:

Hat man ihn per Displayport am PC angeschlossen und dieser schickt die Anzeige in den Display geht er zunächst zwar wie vorgesehen in den Standby, wacht nach 20 Sekunden auf Signalsuche wieder auf. Eh?

Der Herstellersupport hat einigermaßen schnell einen Workaround angeboten: In den Einstellungen unter System-Einstellungen auf die zweite Seite blättern und die Auto-Quellerkennung ausschalten. Damit muss man bei der Verwendung von mehreren Geräten zwar manuell hin und her schalten, für meine Anwendung ist das aber nicht nötig. Ein Bugfix oder Firmwareupdate ist wohl nicht in Aussicht.