Vor knapp 11 Jahren ist bei uns einer dieser Wärmepumpentrockner eingezogen. Das Gerät hat seitdem wirklich viel Wäsche gesehen, einen Haushalt mit dem täglichen Berg an Handtüchern, Bettzeug und Kinderkram trocknet so ein Ding nicht nebenbei. Über die ganze Zeit lief er eigentlich problemlos. Zwei Mal musste ich ihn zerlegen und reinigen, sonst nichts. Genau dieser Punkt ist es aber, der mich diesmal über eine Stunde und ein Teppichmesser gekostet hat.
Der Patient: Bosch WTY87701 Home Professional, ausgerechnet mit dem Aufdruck SelfCleaning Condenser.
Das Symptom ist immer das gleiche: Die Wäsche wird einfach nicht mehr richtig trocken. Teilweise musste ein Programm zwei bis drei Mal durchlaufen, bis das Zeug aus der Trommel wirklich trocken war. Für einen Trockner, der laut Datenblatt 232 kWh im Jahr ziehen soll, sind drei Durchläufe pro Ladung natürlich eine Katastrophe, energetisch wie zeitlich. Meine Frau hatte das Gerät zu dem Zeitpunkt schon angezählt. Es blieb also noch ein Versuch, dann fliegt es raus.
Warum ein Wärmepumpentrockner überhaupt zusetzt
Ein Wärmepumpentrockner ist im Kern ein geschlossener Kreislauf. Die warme, feuchte Luft aus der Trommel wird an einem Verdampfer abgekühlt, das Wasser kondensiert und landet im Tank, dann wird die Luft an einem Kondensator wieder aufgeheizt und zurück in die Trommel geblasen. Dieser Wärmetauscher mit seinen eng stehenden Aluminiumlamellen ist das Herz des Geräts. Und genau dort lagern sich über die Jahre feinste Flusen ab, die das Sieb passieren. Setzt sich die Lamellenfläche zu, kommt kaum noch Luft durch, der Wärmeaustausch bricht ein, und die Wäsche bleibt klamm. Genau das beschreiben auch die einschlägigen Reparaturanleitungen: Flusen in den hinteren Kondensatorlamellen führen zu langen Laufzeiten und einer Wärmepumpe, die sich abmüht.
Die Ironie: ein SelfCleaning Condenser, der trotzdem dicht ist
Das Schöne an meinem Gerät: vorne prangt in großen Lettern SelfCleaning Condenser. Bosch wirbt damit, dass eine manuelle Reinigung des Kondensators nicht mehr nötig sei. Technisch steckt dahinter, dass während eines Trockengangs mehrfach Kondenswasser aus dem Prozess abgezweigt und über die Kondensatorfläche gespült wird, um Flusen wegzuschwemmen. Das funktioniert auch, aber eben nur an der vorderen, gut erreichbaren Fläche, die der Spülstrahl trifft. Die tieferen Lamellen und der Verdampfer dahinter bekommen davon nichts ab. Dort sammelt sich der Feinstaub über ein Jahrzehnt trotzdem an. „Selbstreinigend“ heißt hier also „die vordere Ebene bleibt frei“, nicht „der ganze Wärmetauscher bleibt sauber“. Nach knapp 11 Jahren ist der Unterschied dramatisch.
Hier die Eckdaten zum Gerät und zum Bauteil, um das sich gleich alles dreht:
BSH 00646776, ca. 225 x 145 mm, mit Dichtung und 6 Schrauben
Klappe passt laut Teilekatalog auf
Bosch Serie 6 / Serie 8 / Maxx 7, Siemens iQ300 bis iQ800
Typenschild: E-Nr. WTY87701, Typ WDT66, FD 9505, mit allen Kenndaten für die Ersatzteilsuche.
Wo man rankommt, und wo eben nicht
Das große Flusensieb innen vor der Trommel ist schnell raus, da bekommt man mit schmalen Fingern auch etwas heraus, aber an die spannenden Stellen kommt man so nicht. Vorne am Gerät gibt es noch eine kleine Abdeckung. Rechts dahinter sitzt ein Lüfter, links sieht es zumindest so aus, als hätte dort mal jemand über eine Art Klappe nachgedacht. Und zwar genau an der Stelle, an der man eine Klappe bräuchte, wenn man den Kondensator selbst reinigen will. Bei meinen letzten beiden Reinigungen konnte ich alles andere öffnen und sauber machen, aber an den Kondensator selbst kam ich nie richtig heran. Diesmal sollte es anders laufen.
Die Klappe, die Bosch vergessen hat einzubauen
Jetzt kommt der Teil, der mich erst gewundert und dann geärgert hat. Die Stelle, an der ich die Klappe erwartet hätte, ist im Gehäuse fast schon vorperforiert. Die Kontur ist angedeutet, das Material an der Linie spürbar dünner. Mit einem Teppichmesser lässt sich die Öffnung sehr einfach herstellen, man folgt einfach der angedachten Linie. Heißt im Klartext: Bosch hat die Service-Öffnung konstruktiv komplett vorgesehen, das Werkzeug für die Stanzung existiert, die Position stimmt, nur ausgeliefert wird das Gerät mit zugemachter Wand und ohne Klappe. Für genau diese Lücke gibt es sogar eine eigene Ersatzteilnummer, die 00646776, und einen ganzen Zubehörmarkt. Right to Repair sieht anders aus.
Das herausgetrennte Stück Gehäusewand. Die Kontur war vorperforiert, ein Teppichmesser entlang der angedachten Linie genügt.
Was dann hinter der frisch geschnittenen Öffnung zum Vorschein kam, war wirklich ekelig. Die Flusen hingen als kompakter, grauer Filz komplett vor den Kühlrippen und haben den Wärmetauscher zu einem großen Teil verdeckt. So kann der Kondensator natürlich nicht mehr arbeiten, da geht schlicht keine Luft mehr durch.
Der Blick hinter die frisch geschnittene Öffnung. Ein kompakter Flusenfilz verdeckt fast den kompletten Wärmetauscher.
Alles vorsichtig herausgeholt, abgesaugt und feucht nachgewischt. Die Lamellen waren an einigen Stellen verbogen, die habe ich anschließend so gut wie möglich wieder begradigt. Danach sah der Wärmetauscher wieder so aus, wie er soll: blankes Aluminium, freie Kanäle, Luft kann wieder hindurch.
Nach dem Reinigen und Begradigen der Lamellen: blankes Aluminium, freie Kanäle, die Luft kommt wieder durch.
Variante 1: die Klappe selbst drucken
Bleibt die Frage, wie man das Loch wieder sauber und vor allem dicht verschließt. Ein offenes Gehäuse zieht Falschluft und stört den Kreislauf. Ich habe eine wirklich erstklassige Druckdatei für meinen Bambu Lab X1-Carbon gefunden, ein Nachbau genau der BSH-Klappe 00646776: BSH 00646776 Condenser Door Service Panel auf MakerWorld.
Gedruckt habe ich die Abdeckung in grünem ABS und die Dichtung in TPU 95A. PLA wäre bei den Temperaturen rund um Kondensator und Wärmepumpe keine gute Idee. PLA fängt schon bei etwa 60 Grad an weich zu werden, sein Glasübergang liegt genau in dem Bereich, den so eine Baugruppe im Dauerbetrieb durchaus erreicht. Das Teil würde sich auf Dauer verziehen und die Dichtfläche verlieren. ABS liegt mit einem Glasübergang um die 105 Grad deutlich darüber und steckt die Wärme locker weg. Für die Dichtung will man dagegen etwas Flexibles, das die Spaltmaße ausgleicht und sauber abdichtet, deshalb das weiche TPU mit Shore 95A. Die Materialkombination ist hier kein Gimmick, sondern genau richtig gewählt.
Die in grünem ABS gedruckte Abdeckung von hinten, mit Versteifungsrippen und eingeprägter Teilenummer 00646776.
Die Versteifungsrippen auf der Rückseite und die eingeprägte Teilenummer zeigen, wie sauber die Datei gemacht ist. Mit aufgelegter TPU-Dichtung sieht das dann so aus:
Dieselbe Klappe mit der separat in TPU 95A gedruckten Dichtung.
Montiert wird mit sechs Schrauben in die vorhandenen Dome rund um die Öffnung. Die selbst gedruckte Abdeckung passt erstklassig und dichtet alles ab, wie man es sich wünscht.
Mit sechs Schrauben montiert. Die selbst gedruckte Klappe sitzt passgenau und dichtet sauber ab.
Variante 2: die fertige Klappe kaufen
Wer keinen 3D-Drucker hat, muss trotzdem nicht zum teuren Originalersatzteil greifen. Ich habe auf Amazon für knapp 15 Euro eine passende Abdeckung gefunden: Wartungsklappe für den Wärmetauscher. Die kommt aus spritzgegossenem, talkgefülltem Polypropylen (auf dem Bauteil steht die Materialkennung PP-TV30) und liegt damit thermisch ebenfalls im grünen Bereich. Im Set sind noch etwas Werkzeug zum Reinigen und sogar ein kleines Tool, mit dem sich die Kühlrippen wieder begradigen lassen.
Die gekaufte Alternative für knapp 15 Euro: Wartungsklappe plus Reinigungswerkzeug und ein kleines Tool zum Begradigen der Lamellen.
Auch diese fertige Klappe sitzt sauber in der Öffnung und schließt bündig ab. Auf dem Bauteil sind Teilenummer und Materialkennung mit eingegossen.
Die gekaufte Klappe aus talkgefülltem Polypropylen (PP-TV30) sitzt ebenso bündig. Teilenummer und Materialkennung sind eingegossen.
Beide Lösungen, die selbst gedruckte und die gekaufte, passen perfekt und dichten zuverlässig ab. Ich kann beide vorbehaltlos empfehlen. Wer einen Drucker mit ABS-tauglichem Gehäuse hat, druckt sich die Klappe für ein paar Cent Material selbst, alle anderen sind mit der 15-Euro-Variante inklusive Reinigungswerkzeug bestens bedient.
Und jetzt?
Der Trockner läuft wieder wie am ersten Tag. Eine Ladung, ein Durchlauf, Wäsche trocken. Auf den Fotos vom verdreckten Kondensator sieht es übrigens schlimmer aus, als es sich am Ende angefühlt hat, in einer guten Stunde war alles erledigt. Schöner Nebeneffekt: Ab jetzt brauche ich kein Teppichmesser mehr, sondern schraube die Klappe einmal im Jahr auf und sauge kurz durch. Vielleicht laufen so ja noch einmal 11 Jahre aus dem Teil heraus.
Läuft wieder: eine Ladung, ein Durchlauf. Das Display zeigt Schranktrocken mit normaler Restzeit.
Die kleine Moral: Lasst euch von einem „SelfCleaning“-Aufkleber nicht einlullen. Selbst die selbstreinigenden Geräte setzen sich über die Jahre zu, und ein bisschen Wartung verlängert die Lebensdauer enorm. Dass man dafür erst eine Klappe ins Gehäuse schneiden muss, die der Hersteller komplett vorbereitet, aber nicht freigibt, ist ein eigenes kleines Trauerspiel. Gut, dass es findige Leute mit Druckdateien und Ersatzteilen gibt.
Habt ihr auch so ein Gerät, bei dem die Service-Klappe ab Werk fehlt, oder eine eigene Druckdatei dafür? Dann lasst es mich gerne wissen, ihr dürft mich jederzeit fragen.
Eigentlich wollte ich nur etwas ganz Simples: Aufnahmen von meinem alten DOS-Rechner machen. BIOS-POST, der Speichertest, ein paar DOS-Spiele, einmal das alles sauber als Video festgehalten. Dafür landete ein „VGA to USB 3.0 HD 1080P Video Capture Card“ in meinem Warenkorb, so ein billiger Dongle für ein paar Euro. Spoiler: in genau der Form hat das nicht geklappt. Und warum es nicht klappt, ist die eigentlich spannende Geschichte. Es geht um einen 8051 mit recyceltem Mask-ROM, eine EDID die der Quelle einen Monitor vorlügt, ein „1080p“ das horizontal gar keins ist, und eine Strings-Modifikation die ich bis heute nicht überlistet habe.
Das konkrete Gerät, falls es jemand nachvollziehen will, gibt es bei Amazon unter diesem Link. Es ist einer von hunderten optisch identischen Sticks, die alle den gleichen MacroSilicon-Chipsatz tragen. Die Erkenntnisse hier gelten also für eine ganze Geräteklasse, nicht nur dieses eine Exemplar.
Die Platine des Sticks: VGA-Stecker, USB-A, 3-poliger Audio-Header und der Silkscreen AFN_VGA_Captor 2020/0615_V1.1.
Was steckt auf der Platine?
Aufgeschraubt zeigt sich eine winzige Platine mit Silkscreen-Aufdruck AFN_VGA_Captor 2020/0615_V1.1, einem VGA-Stecker, einer USB-A-Buchse und einem 3-poligen Audio-Header. Drei Halbleiter machen die eigentliche Arbeit:
Ref
Chip
Funktion
U3
MacroSilicon MS2109
8051-basierte UVC-Bridge, USB 2.0 High-Speed
U7
MacroSilicon MS9288A
Analoger VGA-Empfänger (PLL plus ADC plus Scaler)
U2
HK / Holtek 24C16
I²C-EEPROM, 2 KiB
Der MS2109 ist berühmt-berüchtigt. Er steckt in den meisten der spottbilligen HDMI-Capture-Sticks, die seit Jahren durchs Netz geistern. Hier sitzt derselbe Chip in einer VGA-Variante, mit dem MS9288A als analogem Frontend davor. Wie eng die beiden Welten verwandt sind, wird sich beim Mask-ROM-Dump zeigen: die Firmware ist nachweislich aus der HDMI-Variante recycelt.
U3, der MacroSilicon MS2109. Der gleiche 8051-Chip wie in den billigen HDMI-Capture-Sticks, hier in der VGA-Variante.
U7, der MacroSilicon MS9288A. Analoges Frontend mit PLL, ADC und Scaler, lockt das VGA-Signal und digitalisiert es.
U2, der HK 24C16. 2 KiB I2C-EEPROM, hier liegen EDID, Vendor-Strings und die beiden 8051-Patch-Blöcke.
Wie meldet sich das Ding am USB?
Beim Anstecken kommt der erste Hinweis darauf, dass die Verpackung schwindelt. „USB 3.0″ steht drauf, der Kernel sieht aber ein High-Speed-Gerät, also USB 2.0:
usb 1-1.1: new high-speed USB device number 15 using xhci_hcd
usb 1-1.1: New USB device found, idVendor=534d, idProduct=2109, bcdDevice=21.00
usb 1-1.1: Manufacturer: MACROSILICON
usb 1-1.1: Found UVC 1.00 device <unnamed> (534d:2109)
hid-generic 0003:534D:2109.0009: hiddev4,hidraw8: USB HID v1.10 Device
Vendor 0x534d ist MacroSilicon, Produkt 0x2109 der nackte MS2109. Das Gerät enumeriert als UVC-1.00-Kamera plus USB-Audio plus ein vendor-spezifisches HID-Interface. Genau dieses HID-Interface ist später der Schlüssel: darüber kommt man an das EEPROM und sogar an den Arbeitsspeicher des 8051 heran, ganz ohne Lötkolben am I²C-Bus.
Das Werkzeug: ms-tools
Die zentrale Referenz für alles, was mit MS2109 zu tun hat, ist das Projekt ms-tools von Bertold Van den Bergh. Das ist eine kleine Goldgrube: EEPROM lesen und schreiben über die HID-Schnittstelle, Live-Zugriff auf den XDATA-Speicher zur Laufzeit (per eingeschleustem 8051-Patch-Code), das Werkzeug mshack zum Injizieren eigener 8051-Routinen, Ghidra-Skripte mit teildisassemblierter Firmware und ein dump-rom, das den kompletten 64-KiB-Mask-ROM ausliest.
Auf Ubuntu 24.04 ist das schnell gebaut:
sudo apt install golang-go libhidapi-dev libudev-dev
git clone https://github.com/BertoldVdb/ms-tools.git
cd ms-tools/cli && go build -o ../msctl .
Der EEPROM-Dump und eine erste Korrektur
Manche MS2109-Revisionen mögen das übliche RAM-Patching nicht, das ms-tools für komfortable Zugriffe nutzt. Mit --no-patch liest der Dump trotzdem sauber, weil dann der rohe HID-Pfad ohne vorgeschaltete Firmware-Manipulation genommen wird:
Das 0e vor jedem String ist die Pascal-Längenangabe (14 Zeichen). Ab 0x30 beginnt der erste 8051-Patch-Block. Spannend ist die EDID-Sektion ab 0x07A. Mein erster Analyse-Versuch ging davon aus, der klassische EDID-Header 00 FF FF FF FF FF FF 00 sei wegoptimiert und werde erst zur Laufzeit ergänzt. Das war falsch. Nach dem Mask-ROM-Dump und einem genaueren Blick steht der Header sauber im EEPROM. Solche Korrektur-Momente sind mir lieber als ein zu glattes Narrativ, also schreibe ich sie hier auch hin.
Die EDID selbst enthält einen Monitor-Namen MACROSILICON (EDID-Descriptor mit Tag 0xFC), als erstes Detailed-Timing 1280×720 bei 60 Hz mit 74,25 MHz Pixeltakt, ein zweites Timing 1280×768, dazu eine CTA-861-Extension mit nativem VIC=4 (720p60) plus VICs für 1080p60, 1080i, 720p50, 480p und 576p. Es gibt sogar einen HDMI-VSDB-Block mit dem OUI 00:0C:03 von HDMI Licensing und einer Source Physical Address. Eine VGA-only-Platine, die HDMI-Strukturen in ihrer EDID trägt. Das ist schon der erste deutliche Fingerabdruck der gemeinsamen Codebasis.
Der Mask-ROM verrät die Herkunft
Der eigentliche Programmcode des 8051 liegt in einem nicht beschreibbaren Mask-ROM. dump-rom lädt dafür eigenen 8051-Code in den USERRAM, der per MOVC den ROM ausliest und über HID zurückschiebt:
64 KiB komplette CODE-Memory, davon rund 36 KiB belegt im Bereich 0x0000 bis 0x8FFF und weitere 12 KiB ab 0xC000. Die Highlights:
0x7738: eine zweite, im ROM fest verdrahtete Default-EDID, intakt mit Standard-Header, Hersteller-ID „HJW“ und Monitor-Name „HDMI TO USB“. Das ist der Beweis: diese Firmware wurde ursprünglich für den HDMI-Bruder geschrieben.
0x77A9: der ASCII-String „HDMI TO USB“ noch einmal direkt.
0x7087 und 0x709B: die USB-String-Descriptor-Fallbacks „USB Video“ und „USB Digital Audio“ in UTF-16LE. Diese beiden werden uns gleich noch ärgern.
0x0000: der Reset-Vector 02 41 49, also LJMP 0x4149.
Ein LCALL 0xCC10 bei ROM-Adresse 0x478F: das ist der zentrale Einstieg vom Mask-ROM in den EEPROM-Patch-Code, der zur Laufzeit in den RAM kopiert wurde.
Der Bootloader kopiert dabei die EEPROM-Bytes ab Offset 0x30 in den USERRAM ab Adresse 0xCBD0. Die Strings-Sektion 0x10 bis 0x2F wird explizit nicht mitkopiert. Die Patch-Firmware liest die Strings stattdessen zur Laufzeit direkt per I²C aus dem EEPROM und baut daraus die USB-String-Descriptoren an festen RAM-Adressen zusammen. Diese Mapping-Tabelle ist der Kern, um den herum sich die ganze Bastelei dreht:
EEPROM
Code-RAM
Was
0x030
0xCC00
Patch #1, kleine Hook-Routinen
0x07A
0xCC4A
EDID-Header 00 FF FF FF FF FF FF 00
0x080
0xCC50
EDID-Body
0x0FA
0xCCCA
CTA-861-Extension
0x17A
0xCD4A
Patch #2, C51-Startup
0x180
0xCD50
MOV SP,#0x3B; LJMP 0xCD91
0x1C1
0xCD91
main() der Patch-Firmware
Erkenntnis 1: Die EDID lügt der Quelle einen Monitor vor
Über die DDC-Leitungen am VGA-Stecker (Pins 12 und 15) präsentiert der Dongle dem Quell-PC eine EDID. Damit gibt sich das Gerät als Monitor namens „MACROSILICON“ mit 720p60 als nativer Auflösung aus. Genau deshalb liefert ein Quell-PC, an dem gar kein echter Monitor hängt, trotzdem ein sinnvolles Bild: er glaubt, ein 720p-Display gefunden zu haben. So weit, so clever.
Erkenntnis 2: Das „1080p“ ist Marketing
Die UVC-Frame-Tabelle im Mask-ROM listet zwar brav 1920×1080 mit 30 fps als MJPEG. Die Realität sieht anders aus. Mit v4l2-ctl lässt sich die Format-Liste auslesen:
Unkomprimiertes YUYV bei 1080p ist auf magere 5 fps gedeckelt. Das native Detailed-Timing der EDID ist 720p60, das 1080p wird intern hochskaliert. Und USB 3.0 ist nirgends, der Chip kann nur High-Speed. Drei Behauptungen auf der Verpackung, drei mal geschummelt. Auf die 5-fps-Grenze komme ich am Ende noch genauer zurück, die hat einen sehr konkreten technischen Grund.
Erkenntnis 3: Kein DOS, und das lässt sich nicht reparieren
Jetzt zum eigentlichen Frustpunkt, der Grund, warum mein DOS-Plan scheiterte. Die UVC-Frame-Tabelle enthält keine 70-Hz-Modi. Ein DOS-BIOS gibt aber im Standard-VGA-Textmodus 720×400 bei 70 Hz aus. Das analoge Frontend, der MS9288A, könnte dieses Signal vermutlich locken, der Horizontaltakt von 31,469 kHz ist derselbe wie bei 640×480 bei 60 Hz. Aber die MS2109-Firmware bietet schlicht keinen passenden UVC-Frame-Mode an, an dem ein Aufnahmeprogramm andocken könnte.
Und das Bittere: im EEPROM kann man das nicht reparieren. Die Frame-Tabelle liegt im nicht-flashbaren Mask-ROM. Das EEPROM steuert nur EDID, Strings und ein paar Patch-Routinen, nicht die Liste der angebotenen Auflösungen. Wer mit so einem Dongle echte DOS-Signale aufnehmen will, kommt um eine vorgeschaltete Scaler-Box nicht herum. Mehr dazu am Ende.
Was wir trotzdem geändert haben: die EDID
Wenn die Frame-Tabelle schon unantastbar ist, dann wenigstens die EDID anfassen. Ich habe das erste Detailed-Timing von 720p60 auf 1920×1080 bei 60 Hz umgeschrieben (148,5 MHz Pixeltakt, das Standard-CEA-861-1080p60-Timing), die EDID-Checksumme neu berechnet und das EEPROM zurückgeflasht. Das neue DTD #1 sieht so aus:
Nach einem Replug liefert das Gerät die modifizierte EDID. Zumindest dachte ich das. Ob sie auch wirklich bei einer Quelle ankommt, war eine ganz eigene Odyssee, dazu komme ich beim A/B-Test. Vorweggenommen: Die Mod tut technisch genau das, was sie soll, sie ändert nur am Ende nichts an dem, was aufgenommen wird. Eine reine „ich sage der Quelle, ich kann 1080p“-Kosmetik.
Was NICHT geklappt hat: die Strings
Das ist der lehrreichste Teil des Projekts, gerade weil er bis heute offen ist. Ich wollte die USB-Function-Strings ändern, aus dem hässlichen „AFN_Cap video“ sollte ein sauberes „VGA Capture HD“ werden. Das EEPROM-Schreiben verifiziert sauber per Readback-Hash. Die EDID-Mod aus demselben Reflash funktioniert. Aber die Strings fallen nach dem Replug auf die ROM-Defaults „USB Video“ und „USB Digital Audio“ zurück. Irgendetwas in der Firmware sagt „nein“.
Also empirisch rangegangen, drei Single-Byte-Tests in der Strings-Region 0x10 bis 0x2F: einmal ein ASCII-Zeichen geändert, einmal ein FF-Padding-Byte, einmal das Längen-Byte. Jeder einzelne dieser Eingriffe löst den Fallback aus. Egal welches Byte, egal welcher Inhalt. Das ist eine klare Indikation für ein Content-Gate über die gesamte 32-Byte-Region, nicht für eine simple Längen- oder Inhaltsprüfung an einer Stelle.
Ein Gegencheck zur eigenen Analyse hat ein paar Punkte geschärft. Die Bytes 0x02 und 0x03 (03 8E) sind verifiziert die Payload-Länge und keine Checksumme: 910 Bytes ab 0x30 reichen bis 0x3BD, exakt bis vor den End-Marker. Der Verdacht: ein lokales Validierungs-Gate auf den 32-Byte-Strings-Slots, wahrscheinlich ein Hash oder ein Exact-Content-Compare in einem ROM-Helper, nicht im Patch-Code selbst. Ein Quervergleich mit dem usbkvm-Projekt zeigt dasselbe Header-Muster bei verwandter Hardware.
Der spannendste Nebenbefund kam aus einem XDATA-Boot-Trace bei 0xC630 bis 0xC67F: die „AFN_Cap“-Strings landen gar nicht dauerhaft im RAM. Was dort steht, ist die Fallback-Variante. Die echten Strings werden erst zur Laufzeit beim USB-GetDescriptor aus dem EEPROM gebaut, und genau in diesem Moment greift offenbar das Gate. Wer das knacken will, müsste den USB-Control-Transfer mit usbmon und Wireshark während der Enumeration mitschneiden, die ROM-Helper bei 0x6345 und Nachbarn disassemblieren, oder mit mshack einen Bypass-Patch auf den Fallback-Branch setzen. Der schnellste Weg wäre allerdings, ein vom offiziellen MacroSilicon-Windows-Tool editiertes EEPROM byteweise gegen mein eigenes zu diffen. Dieses Tool schreibt vermutlich versteckte Metadaten mit, die das öffentliche Reverse-Engineering noch nicht dokumentiert hat. Das ist mein heißester Kandidat fürs Strings-Mysterium, aber bisher unbewiesen.
Der A/B-Test, oder: die Suche nach einer ehrlichen VGA-Quelle
Ich wollte zwei Dinge empirisch klären. Erstens: Kommt die modifizierte 1080p-EDID überhaupt bei der Quelle an? Zweitens: Löst das Ding echtes 1080p auf oder ist das hochskalierter Matsch? Beides braucht eine VGA-Quelle, die ihre DDC-Leitung auch wirklich ausliest. Das war schwerer zu finden als gedacht.
Erster Anlauf, ein Notebook mit „VGA-Out“. Plot-Twist: der VGA-Anschluss lief über einen aktiven DisplayPort-auf-VGA-Adapter und tauchte als DP-4 auf. Der Adapter liefert ein eigenes synthetisches EDID („NVD“, „LCD_VGA“, 1280×1024). Das ist nicht das EDID aus dem Dongle. Der EDID-Pfad vom Dongle bis zur GPU ist also unterbrochen. Erste Lehre: aktive DP-auf-VGA-Adapter verhalten sich wie eine eigene EDID-Quelle und maskieren alles dahinter.
Zweiter Anlauf, ein ThinkPad L560 mit echter VGA-Buchse hinten. Wieder gescheitert, und zwar aus einem prinzipiellen Grund. Ab Haswell und Skylake hat Intel den analogen RAMDAC komplett aus der GPU geworfen. Die physische VGA-Buchse hängt an einem Onboard-DP-auf-VGA-Bridge-Chip. Der Kernel verrät es selbst:
Null Byte EDID. Die Bridge reicht das DDC vom Dongle nicht durch, der Connector bietet nur die VESA-Default-Modi an. Exakt dasselbe Problem wie beim ersten Notebook, nur diesmal onboard statt als Dongle. Auf beiden getesteten Bridge-Pfaden kam die EDID des Capture-Sticks nicht zur Quelle durch. Als Trend lässt sich sagen: neuere Intel-Notebooks haben den analogen RAMDAC verloren (der fiel etwa um Haswell und Broadwell, also rund 2013 bis 2015) und führen „VGA“ über DP-Bridges, die DDC abschneiden. Das als „kein Notebook taugt je“ zu verkaufen wäre übertrieben, es ist ein Trend, kein Beweis.
Ein netter Nebenbefund vom L560, den ich erst für einen kaputten Aufbau hielt: nach jedem Auflösungswechsel liefert der Dongle erstmal 1 bis 6 Sekunden ein komplett schwarzes Bild, bis die MS9288A-PLL wieder eingerastet ist. Ich hatte reihenweise schwarze Frames gegrabbt und schon den Analogpfad für tot erklärt. In Wirklichkeit hatte ich nur immer ins Re-Lock-Fenster reingeschossen. Mit 4 bis 6 Sekunden Settle-Zeit kommt das Bild stabil. Passt zur dokumentierten Sync-Trägheit des Chips.
Der A/B-Test selbst
Trotz blockiertem DDC habe ich den A/B durchgezogen, einfach um es schwarz auf weiß zu haben. Als Quelle ein 1920×1080-Testbild mit vier Quadranten aus 1-Pixel-Gittern: Schachbrett, vertikale Linien, horizontale Linien, Diagonale. Dazu grüne Eck-Marker, um sicher zu sein, dass der ganze Frame ankommt.
Das Quell-Testbild: vier Quadranten mit 1px-Schachbrett, Vertikal-, Horizontal- und Diagonalgittern, dazu Eck-Marker.
Erst der Befund, der mich am meisten interessiert hat: 1px-Vertikallinien und Schachbrett kollabieren zu flachem Grau, das horizontale Feindetail ist weg. 1px-Horizontallinien und Diagonale zeigen schwache Resttextur. Die vertikale Auflösung kommt also weitgehend durch (jede Scanline ist eine eigene analoge Zeile), die horizontale ist deutlich begrenzt. Wichtiges Ehrlichkeits-Caveat: das ist die komplette Analogkette, also Bridge-DAC im L560, Kabel und MS9288A-ADC zusammen. Mit diesem Aufbau lässt sich nicht sauber trennen, wieviel davon der Dongle ist.
Dann der eigentliche EEPROM-A/B. EEPROM gegen das Original-Backup getauscht, Readback-Hash jedes Mal verifiziert. Etwas, das ich erst lernen musste: nach dem Flashen muss der Dongle einmal physisch ab- und wieder angesteckt werden. Ein reiner USB-Bus-Reset reicht nicht, der 8051 läuft einfach weiter und liest das neue EEPROM gar nicht ein. Software-seitig ging das nicht (kein schaltbarer Port), also von Hand. Die Zahlen, ImageMagick MAE auf einer Skala von 0 bis 1:
Vergleich
MAE
pro 255
Rauschen mod3 (zwei Aufnahmen, gleiches EEPROM)
0,0041
1,05
Rauschen Original
0,0043
1,10
mod3 gegen Original
0,0071
1,82
Der Cross-Wert liegt nur minimal über dem Rauschpegel. Das maximal verstärkte Differenzbild zeigt keine strukturierte Änderung, nur MJPEG-Blockrauschen in den hochfrequenten Quadranten. Die kleine Differenz ist Re-Lock- und AGC-Varianz zwischen den Sessions, nicht das EDID.
Maximal verstärkte Differenz: mod3-EDID gegen Original-EDID. Nur Blockrauschen, keine Struktur. Die EDID-Mod ändert am Bild nichts.
Fazit des A/B: Die EDID-Mod von 720p auf 1080p verändert das aufgenommene Bild exakt null. Aus erstem Prinzip war das klar, die EDID ist das, was das Gerät der Quelle anbietet, sie steuert nicht den Aufnahmepfad. Aber jetzt steht es empirisch da.
Endlich eine echte Analog-Quelle, und zwei dicke Befunde
Dritter Anlauf, diesmal ein Desktop mit einer NVIDIA GeForce GT 630 (Kepler). Kepler hat noch einen echten analogen RAMDAC, über einen passiven DVI-I-auf-VGA-Adapter kommt echtes analoges VGA raus. Endlich die Hardware, die den Notebooks fehlte.
Befund 1: Die EDID-Mod ist sogar grundsätzlich für die Katz. Der NVIDIA-Treiber cached die analoge EDID hartnäckig (analoges VGA hat kein Hotplug), also einmal lightdm neugestartet für einen frischen Read. Das Ergebnis im Xorg-Log:
(--) NVIDIA(GPU-0): CRT-0: connected
(WW) NVIDIA(0): CRT-0 does not have an EDID
Der Dongle liefert auf seinem VGA-Eingang gar keine DDC und keine EDID. Sauber belegt: derselbe Adapter hat vorher die EDID eines echten Monitors gelesen (ein Fujitsu P24-9, mit 1920×1080 und physischen Maßen), der Adapter reicht DDC also durch. Es ist der Dongle, der nichts treibt. Das kippt eine Annahme aus meinen eigenen Notizen, wo stand, das Patch-Modul beantworte „wahrscheinlich“ DDC-Reads. Dieses „wahrscheinlich“ war nie gemessen.
Ehrlich bei der Konfidenz bleiben: hoch dafür, dass in diesem GT-630-Test keine lesbare EDID vom Dongle kam. Nur mittel für das universelle „keine Quelle sieht die EDID je“. Restzweifel, die ich noch nicht ausgeräumt habe: NVIDIA-Eigenheiten bei analogem DDC, ob die Dongle-DDC die 5 Volt auf VGA-Pin 9 braucht, oder ob der DDC-Responder erst nach Sync-Lock aufwacht. Ein Pin-9-Check plus Logic-Analyzer auf den Pins 12 und 15 (mit dem Fujitsu als Positiv-Kontrolle) würde es hart machen. Arbeitshypothese: auf dem getesteten echten Analogpfad präsentierte der Dongle keine lesbare EDID, vermutlich weil der VGA-DDC-Pfad in der geteilten HDMI/VGA-Codebasis schlicht nicht verdrahtet ist. HDMI hat HPD und DDC, VGA hier offenbar nicht.
Befund 2: Das „1080p“ ist vertikal echt, horizontal Fake. Mit echtem RAMDAC konnte ich endlich den Dongle-Anteil am Blur isolieren (eigene xorg.conf mit UseEDID false und forciertem 1080p-Modeline, NVIDIA lehnt xrandr-Modelines ab). Testbild: reine 1px-Schwarz-Weiß-Gitter per xsetroot. Das Resultat, gemessen als Standardabweichung der Luma (ein ideales Gitter liegt bei rund 128, flaches Grau bei 0):
1px-Gitter bei echtem Analog-1080p
Std-Abw.
Bedeutung
horizontale Linien
119
vertikal sauber aufgelöst
vertikale Linien
0,6
horizontal komplett verschmiert
Schachbrett
0,55
weg
Echte Analog-Quelle (GT 630): links das vertikale 1px-Gitter zu Grau verschmiert, mittig horizontale Linien gestochen scharf, rechts das Schachbrett weg.
Der Dongle hat also echte 1080 Zeilen vertikal, aber horizontal kommt weit weniger als 1920 Pixel an. Und weil hier kein Bridge mehr dazwischen sitzt: der Blur ist der Dongle selbst, nicht das billige Notebook. Das ist die belastbare Aussage.
Den Mechanismus habe ich auf einen Vorschlag aus dem Gegencheck hin gleich nachgemessen, ein Phasen- und Balkenbreiten-Test. Das 1px-Gitter ist bei Phase 0 und Phase 1 gleich grau (Std-Abw. 0,18 gegen 0,19), ein PLL- oder Phasen-Mislock ist damit ausgeschlossen, sonst würde der 1px-Versatz den Kontrast kippen. Und der Kontrast steigt sauber mit der Balkenbreite: 1px liegt bei rund 0, 2px bei 35, 3px bei 61, 4px bei 79 (Ideal rund 128). Das ist die klassische Tiefpass-Signatur, also ein echtes Horizontal-Auflösungs-Limit und kein Lock-Artefakt. Ob das an der ADC-Abtastrate oder an einem internen Rescale liegt, kann ich noch nicht trennen, aber beides heißt: der Dongle begrenzt die Horizontalauflösung.
Balkenbreiten-Rampe: 1px bleibt grau, ab 2px wird Kontrast sichtbar. Klassische Tiefpass-Signatur, ein echtes Horizontal-Limit.
Warum YUYV bei 1080p nur 5 fps macht
Zum Schluss noch die berüchtigte 5-fps-Grenze, diesmal gemessen statt aus der Tabelle abgeschrieben (Quelle GT 630 bei 1080p60, v4l2-ctl --stream-mmap):
Format bei 1920×1080
gemessen
MJPEG
29 fps (Tabelle: 30)
YUYV (unkomprimiert)
exakt 5,0 fps
Meine erste Erklärung mit „ungefähr 40 MB/s USB-2.0-Bandbreite“ war zu schludrig. Der genaue Grund ist das Payload-Limit des isochronen UVC-Endpoints. Das größte Altsetting des Video-Endpoints ist 3 mal 1024 Bytes pro Microframe, also 24,576 MB/s (steht so im lsusb -v). Unkomprimiertes YUYV bei 1080p sind 1920 mal 1080 mal 2 Bytes, also 4,15 MB pro Frame. Die Firmware-Frametabelle ist genau so gewählt, dass die YUYV-Raten knapp darunter passen:
1080p mal 5 fps = 20,7 MB/s
720p mal 10 fps = 18,4 MB/s
480p mal 30 fps = 20,7 MB/s
Also keine generische „USB-2.0-Bandbreite“, sondern der High-Speed-Isoch-Endpoint plus die fest verdrahteten Frametabellen. MJPEG komprimiert vorher, deshalb bleiben dort 30 fps bei 1080p und bis zu 60 bei 720p und darunter. Klare Ansage: am MS2109 ist MJPEG bei hoher Auflösung Pflicht. Und „USB 3.0″ auf der Verpackung ist und bleibt gelogen, das Ding enumeriert als USB-2.0-High-Speed, ohne SuperSpeed.
Stabiles Device-Naming per udev
Damit das Gerät im Alltag immer unter demselben Pfad auftaucht, eine udev-Regel. Die Regeln stehen bewusst jeweils auf einer Zeile, weil mehrzeilige Fortsetzungen mit Backslash schnell zur Fehlerquelle werden:
Die GOTO-Konstruktion ist nötig, weil ATTRS{product}!="..." nicht so funktioniert, wie man denkt. udev sperrt die Attribut-Suche auf einen Parent-Device-Walk, und „Fehlen eines Attributs“ verhält sich anders als ein echtes Ungleich. Deshalb der Umweg über ein positives Match plus Sprungmarke.
Fazit, und der Workaround der wirklich hilft
Was bleibt? Der Dongle ist ein nettes Studienobjekt, aber für mein ursprüngliches Ziel, alte DOS-Signale aufnehmen, ist er unbrauchbar. Es gibt keine 70-Hz-Modi, und reparieren lässt sich das nicht, weil die Frame-Tabelle im Mask-ROM festgebrannt ist. Das „1080p“ ist horizontal Marketing, „USB 3.0″ eine glatte Lüge, und die EDID-Mod ist auf dem getesteten Analogpfad wirkungslos, weil der Dongle gar keine EDID treibt. Drei Korrektur-Momente gegenüber meinen ersten Annahmen, alle drei lehrreicher als wenn alles gleich funktioniert hätte.
Wer wirklich exotische VGA-Signale wie DOS-Textmodi sauber aufnehmen will, schaltet eine externe Scaler-Box vor. Mein Tipp ist GBS-Control, eine offene Firmware für die rund 20 Euro teuren GBS-8200-Boards. Sie nimmt das krumme Quellsignal, lockt sauber und gibt ein normgerechtes Bild aus, das jeder Capture-Stick frisst. Die andere Liga ist der Open Source Scan Converter, dessen Firmware-Update ich hier schon beschrieben habe. Wer es noch günstiger mag, fängt einen gebrauchten Extron-Scaler aus einer Konferenzraum-Ausmusterung.
Offen bleibt das Strings-Mysterium (ohne das Vendor-Tool komme ich an den Gate-Algorithmus nicht ran), die Disassembly des zweiten Patch-Blocks in Ghidra, ein Latenz-Benchmark für den Einsatz als KVM-Console-Viewer, und der finale DOS-Test mit GBS-Control davor. Material für einen zweiten Teil ist also reichlich da.
Habt ihr selbst schon so einen MS2109-Stick auseinandergenommen oder das Strings-Gate geknackt? Dann lasst es mich gerne wissen, ihr dürft mich jederzeit fragen.
Vor ein paar Wochen habe ich hier den TC1 Multifunction Tester mit der quelloffenen m-firmware geflasht. Seitdem liegt ein zweiter Bauteiltester aus genau dem gleichen Dunstkreis bei mir auf dem Tisch: ein LCR-T4-Plus mit gelber Platine, eingebautem ZIF-Sockel und Beschriftung „91make.taobao.com“ auf der Rückseite. Das billige Gegenstück zum TC1, vom selben Hersteller-Cluster, gleiche Firmware-Familie. Eigentlich ein gemütlicher Folge-Sonntag, dachte ich.
Ausgangslage: aufgeklapptes Display, ZIF-Sockel, blauer Start-Button. Rechts vom Button der ISP-Header mit den (falsch beschrifteten) Silkscreen-Labels.
Zur Vorgeschichte gehört ein erster T4-Plus, den ich vor Jahren mal gekauft hatte. Das Gerät arbeitet bis heute, sein Display allerdings ist tot. Der COG-Controller unter dem Epoxy-Klecks auf dem ST7565R hat aufgegeben, der MCU lebt noch, aber zeigen kann er nichts mehr. Vor ein paar Wochen habe ich aus einer Resterampe ein zweites Exemplar geordert, gleicher Aufdruck, gleiche PCB-Revision. Plan: einmal Backup-Flash und dann beide Geräte parallel mit m-firmware betreiben, eines als Bastelreserve.
Aus „schnell mal das gleiche Flash-Profil wie beim ersten T4-Plus drüberbügeln“ wurde ein ganzer Nachmittag mit komplett schwarzem Display, abgeschnittenem Cursor, einem Tester der sich beim Loslassen des Buttons sofort wieder ausschaltet und am Ende der Erkenntnis, dass die zentrale Falle nicht in der Firmware steckt, sondern in einem winzigen Bauteil neben dem MCU.
Was steckt im T4-Plus v2?
Anders als der TC1 mit seinen zwei Chips (ATmega plus STC für das Power-Management) ist der T4-Plus ein Single-MCU-Design. Auf der Rückseite klebt genau ein nennenswerter Halbleiter, der Rest ist Spannungsteiler, drei Transistoren für die Power-Latch-Schaltung und der Quartz.
Rückseite des PCB mit dem ATmega328P, dem silbernen Quartzblock daneben (8 MHz, nicht 16 wie beim ersten Exemplar!) und dem 9V-Block-Anschluss.
Close-up unter der Lupe: ATMEL MEGA328P-U-TH, Date-Code 2009SG8. Originalsilizium von Atmel/Microchip, kein LGT8F328-Klon wie auf manchen jüngeren Boards.
U1: ATmega328P-U-TH im TQFP-32-Gehäuse, Signatur 0x1e950f, 32 KB Flash, 2 KB SRAM, 1 KB EEPROM. Der Date-Code 2009SG8 stammt aus 2020, Production-Code-Pattern passt zu echtem Microchip-Silizium. Auf gefälschten Klonen sieht das Lasermarkings-Pattern deutlich anders aus, das Schriftbild ist hier sauber, also passt das.
Der Display-Controller sitzt unter dem schwarzen Epoxy-Blob auf dem LCD selbst und ist ein ST7565R mit 128 mal 64 Pixel monochromem STN-Panel, gelb-grüne Hintergrundbeleuchtung. Klassische COG-Bauform. Daten kommen seriell über vier GPIO-Leitungen rein. Kein I2C, sondern SPI-Bitbang vom MCU getrieben.
Stromversorgung läuft über einen 9V-Block mit Spannungsteiler 10k zu 3.3k auf einem ADC-Pin. Bedienelement: ein einziger blauer Start-Button, kein Drehgeber, kein IR-Empfänger, kein USB. Das Ding ist ein Wegwerf-Standalone im besten Sinne, nichts dran was schiefgehen kann.
Und dann ist da noch dieser kleine silberne Quartzblock direkt neben dem MCU. 8.000 steht da. Acht Megahertz. Beim ersten T4-Plus von vor Jahren habe ich 16 MHz im Hinterkopf, ich notiere mir die 8 MHz pflichtbewusst, denke aber „nett, anderer Quartz“ und mache ansonsten erstmal weiter. Spoiler: genau dieser Eintrag wird Stunden später zum Schlüssel.
ISP-Header finden, und der Aufdruck lügt
Der ISP-Header sitzt versteckt unter der Display-Platine, ein simples 2×3-Pad-Grid ohne aufgelötete Stiftleiste. Auf der Rückseite finden sich Silkscreen-Hinweise: mis, mosi, sck, reset, plus die beiden Stromversorgungspads. Lustig: bei diesem Board sind die beiden Datenleitungen vertauscht beschriftet. Was als mis markiert ist, trägt physisch MOSI; das mosi-Pad ist tatsächlich MISO.
Aufgefallen ist mir das beim ersten Signatur-Read mit dem Arduino Uno als ISP-Programmer. Wenn man stur nach Silkscreen verkabelt, antwortet der Chip mit lauter 0x00. Sobald die Leitungen getauscht werden, kommt eine saubere Signatur. Heißt für die Praxis: bei diesem Board nicht auf den Aufdruck verlassen, sondern Pin für Pin mit dem Durchgangsprüfer gegen die Chip-Pins verifizieren. Standard-ISP-Pinout auf dem ATmega328P im TQFP-32 ist Pin 17 MOSI, Pin 18 MISO, Pin 19 SCK, Pin 29 /RESET.
Arduino Uno mit ArduinoISP-Sketch als Programmer. Display zur Seite geklappt, vier Datenleitungen plus 5V und GND. Genauso wie beim TC1, gleiche Hardware, gleiche Flag-Kombination.
Verkabelung an den richtigen Pads (Arduino-seitig), gilt für beide T4-Plus-Boards:
Arduino D10 -> RESET (T4-Plus Pad RESET)
Arduino D11 -> MOSI (T4-Plus Pad „mis" bei diesem Klon!)
Arduino D12 -> MISO (T4-Plus Pad „mosi" bei diesem Klon!)
Arduino D13 -> SCK (T4-Plus Pad SCK)
Arduino 5V -> VCC
Arduino GND -> GND
Sobald die Signatur sauber kommt, ist die halbe Miete drin:
Beim TC1 ging das Backup nicht, weil die Lock-Bits auf 0xC0 standen und das Auslesen geblockt haben. Beim T4-Plus v2 habe ich Glück: Lock-Byte ist 0xFF, also komplett offen. Vor dem ersten Flash zieht man sich also bitte unbedingt das Original einmal komplett herunter, Flash und EEPROM:
Fuses kamen so zurück: lfuse=0xF7, hfuse=0xD9, efuse=0xFD, lock=0xFF. Hat man das im Kasten, kann man auch beruhigt herumprobieren. Notfalls geht es per avrdude -U flash:w: jederzeit wieder auf den Auslieferungszustand zurück.
Erster Flash und ein völlig schwarzes Display
Quelle für die neue Firmware ist wie beim TC1 die m-firmware von madires, aktuell Version 1.56m. Im Repo liegt unter Software/Firmware/m-firmware/ der Source mit allen Config-Templates für die diversen MCU-Varianten. Für den ATmega328P ist das config_328.h, gemeinsame Optionen in config.h, build-Flags im Makefile.
Mein erster Anlauf orientierte sich an dem, was beim ersten T4-Plus damals funktioniert hatte. Display ST7565R aktivieren, BAT_DIVIDER mit 10k zu 3.3k, Short-Circuit-Menu an, MCU auf atmega328 (ohne das nachgeschobene P, sonst greift der #if defined(__AVR_ATmega328__)-Guard in config_328.h nicht und der Build wirft undefinierte BUTTON_PIN-Symbole), Frequenz pflichtbewusst auf FREQ = 16 wie beim ersten Board.
Make, flash, einschalten, und dann das hier:
Display nach erstem Flash mit Default-FLAG_RATIO_65: komplett dunkel. Klassisches Symptom eines zu hoch eingestellten internen LCD-Spannungsteilers.
Komplett schwarz. Kein Boot-Banner, keine Kontrast-Stufe, einfach nur eine schwarze Fläche. Mein erster Gedanke war natürlich: Display kaputt, gleicher Spaß wie beim ersten T4-Plus. Aber die Backlight-LEDs leuchten, und im Streiflicht erkennt man, dass die Pixel-Anordnung sichtbar ist, nur eben in „alle Pixel an“-Stellung. Das ist kein toter Controller, das ist ein lebender Controller mit zu hohem internem LCD-Bias.
Im m-firmware-Source liegt direkt ein Clones-Verzeichnis mit Hinweisen zu bekannten Klon-Variationen. Für den verwandten LCR-T5 steht dort genau dieser Workaround: bei manchen ST7565R-Panels ist der per Software gesetzte Bias zu hoch, der typische Default-Befehl CMD_V0_RATIO | FLAG_RATIO_65 muss runter auf FLAG_RATIO_55 oder sogar FLAG_RATIO_45. Geändert wird das in ST7565R.c in der Funktion LCD_Init():
/* set contrast: resistor ratio 5.5 */
LCD_Cmd(CMD_V0_RATIO | FLAG_RATIO_55); /* statt FLAG_RATIO_65 */
Mit dieser einen Zeile ändert sich alles. Neuer Build, flashen, und siehe da, plötzlich sind tatsächlich Pixel sichtbar.
Display-Tuning: Orientierung, Kontrast und der abgeschnittene Cursor
„Pixel sichtbar“ heißt noch lange nicht „lesbar“. Was da auf dem Display erscheint, sind erstmal Hieroglyphen kopfüber, spiegelverkehrt, mit komischen Pixel-Mustern an Stellen, an denen eigentlich Zeichen stehen sollten. Das ist die klassische ST7565R-Inbetriebnahme: drei Defines steuern Orientierung und Kontrast, alle drei muss man am eigenen Panel kalibrieren.
Bei meinem Panel sind beide FLIP-Defines aus, was unintuitiv klingt aber stimmt. Der Kontrast landet final bei 22. Nach ein paar Build-Iterationen sieht das so aus:
Zwischenstand: Orientierung und Kontrast passen, „1-||-3 .15pF“ gut lesbar. Aber das blinkende Cursor-Symbol rechts ist abgeschnitten, weil LCD_OFFSET_X den gesamten Inhalt um vier Pixel nach rechts schiebt.
Klassischer Fall: bestimmte ST7565R-Panel-Varianten brauchen einen X-Offset von vier Pixel, weil deren sichtbarer Bereich rechts beginnt. Andere wiederum nicht. Das Define LCD_OFFSET_X erzwingt genau diese Verschiebung. Mein Panel will sie nicht, also raus damit:
//#define LCD_OFFSET_X /* deaktiviert: kein +4 Pixel Shift */
Nach dem Auskommentieren sitzt der Bildinhalt zentriert, der Cursor ist vollständig sichtbar. Erste komplette Messung lesbar: ein simpler Widerstand.
An dieser Stelle wäre die Geschichte normalerweise vorbei. Display tut, Buttons drücken, Messen, fertig. Wäre da nicht das Problem mit dem Einschalten.
Das Power-Latch-Drama
Der T4-Plus hat einen blauen Druckknopf. Den drückt man, der Tester bootet, misst, schaltet sich nach Inaktivität von alleine wieder ab. So weit der Plan. Mein frisch geflashtes Board allerdings macht etwas Ärgerliches: Knopf drücken, Display bootet kurz an, Knopf loslassen, sofort wieder aus. Das ist kein „Auto-Power-Off nach Timeout“, das ist „MCU verliert beim Loslassen die Stromversorgung“. Klassischer Power-Latch-Bug.
Erster Reflex: irgendein POWER_CTRL-Pin in der Config ist falsch. Die m-firmware hat einen Define für den Pin, an dem der MCU nach dem Boot ein HIGH-Signal anlegen muss, um sich selbst am Leben zu halten. Auf den meisten Boards heißt der Pin PD6 oder ähnlich. Also durchprobiert: PD6, PD7, PD4, PD3, alles was an freien Pins noch übrig ist. Kein Erfolg. Egal welcher Pin, sobald der Finger den Button verlässt, ist Schluss.
Zeit für die Multimeter-Tour über die Latch-Schaltung. Auf der Platine sitzen drei Transistoren um den Power-Knopf herum: Q1 ist ein S9015 (PNP), schaltet die 9V auf die Versorgung. Q2 und Q3 sind beide S9014 (NPN) und treiben gemeinsam mit dem Button-Kontakt die Basis von Q1. Durchgangsmessungen ergeben:
Das ist also gar kein „Firmware schaltet POWER_CTRL HIGH“-Design. Die Latch-Schaltung ist passiv über die /RESET-Leitung des MCU aufgebaut. Solange der ATmega läuft, liegt /RESET auf HIGH (intern hochgehalten), und über den 27k zur Basis von Q3 bleibt der Transistor durchgesteuert, Q1 hält die Versorgung an. Drückt man den Button, zieht der Q3-Basis kurz auf GND-Potenzial Richtung positiv und triggert das Hochfahren über einen leicht anderen Pfad. Aber sobald der Boot durch ist und der MCU /RESET HIGH hält, läuft das Ganze von alleine.
Heißt: an meinem Board sollte das auch ohne firmware-seitiges POWER_CTRL funktionieren. Tut es aber nicht. Spannungsmessung unter Strom zeigt: Q3-Basis bleibt dauerhaft bei 0V, der Transistor schaltet nie sauber durch. Aber warum, wenn doch /RESET nach erfolgreichem Boot eigentlich HIGH sein müsste?
An dieser Stelle saß ich gefühlte zwei Stunden an dem Tisch und habe mit dem Multimeter zwischen MCU-Pinout, Transistor-Basen und 9V-Schiene hin- und hergemessen. Mein Verdacht war zwischendurch ein toter Transistor, ein kalter Lötpunkt, ein verkokelter Trace unter dem schwarzen Lötstopplack. Alles falsch.
Der Aha-Moment im Makefile eines fremden Forks
Irgendwann habe ich aus Verzweiflung angefangen, fremde Firmware-Forks für genau dieses Board zu lesen. Es gibt eine zweite quelloffene Linie neben der m-firmware: die k-firmware (das „k“ steht für Karl-Heinz Kübbeler, den Original-Autor), und davon wiederum diverse Forks. Einer davon ist Palingenesis‘ Fork mit einem dedizierten T4-v2-Build-Profil. Ich öffne dessen Makefile, und der Blick fällt auf eine einzelne Zeile:
OP_MHZ = 8
Acht. Megahertz. Genau die Zahl, die ich Stunden vorher auf dem Quartz gelesen und in mein Notizfeld geschrieben hatte. Genau die Zahl, deren Bedeutung ich nicht richtig zu Ende gedacht hatte. Mein Build der m-firmware lief mit FREQ = 16, weil ich davon ausgegangen war, dass das T4-Plus-Board immer 16 MHz Quartz hat. Tut es eben nicht. Beim zweiten Exemplar ist ein 8-MHz-Quartz drauf.
Was das praktisch bedeutet: wenn die Firmware glaubt, sie laufe auf 16 MHz, aber tatsächlich nur 8 MHz Takt verfügbar sind, läuft jede Operation effektiv mit halber Geschwindigkeit. Jedes Timer-Tick, jede Schleife, jede ADC-Konversion dauert doppelt so lang. Im Falle der Initialisierungssequenz heißt das: bis der MCU im Bootcode an der Stelle ist, an der POWER_CTRL HIGH gesetzt wird (oder bis /RESET stabil HIGH ausgegeben wird), ist das Zeitfenster, in dem der Button noch gedrückt ist, schon längst vorbei. Der Latch greift nicht, der Tester schaltet sich beim Loslassen ab.
Drei Buchstaben im Makefile geändert:
FREQ = 8
Neu kompiliert, geflasht. Knopf gedrückt. Display kommt. Knopf losgelassen. Display bleibt an. Der Tester hält sich selbst am Leben. Zwei Stunden Diagnose-Drama wegen einer einzigen Zahl im Makefile, die mit der eigentlichen Hardware nichts zu tun hatte, außer dass die Hardware halt ein anderer Quartz war als gedacht. Genau eine dieser Stellen, an denen man kurz aufsteht und sich was zu trinken holt.
Self-Adjustment und Werte ins Flash schreiben
Nach dem Power-Latch-Fix ist der Tester quasi nutzbar, aber die m-firmware meldet beim Boot „Checksum failure“ für die Adjustment-Werte im Flash. Das ist erwartbar, weil dort ja noch nie eigene Kalibrierwerte gespeichert wurden. Heilmittel: das Service-Menü aufrufen, Self-Adjustment durchlaufen, Werte abspeichern.
Voraussetzung ist, dass UI_SHORT_CIRCUIT_MENU in config.h aktiviert ist. Damit kommt man ins Menü, indem man beim Start alle drei Probes (1, 2, 3) miteinander kurzschließt. Der Tester erkennt das und blendet das Service-Menü ein:
Service-Menü via 3-Probe-Kurzschluss: PWM, IR detector, Opto Coupler, Test, Adjustment, Contrast, Save. Genau das, was man für eine saubere Inbetriebnahme braucht.
Erster Punkt ist „Test“, ein Selbsttest mit allen drei Probes. Anschließend „Adjustment“, da braucht man dann einen 1 µF-Kondensator zwischen Probe 1 und Probe 3. Der Tester misst seinen eigenen internen Ri-Wert, die Eingangskapazität, eine Referenzspannung. Am Ende „Save“, und die Werte landen via DATA_FLASH als Block im Programmspeicher (Self-Programming). Beim TC1 war das genauso, der einzige Unterschied: dort kommen die Daten in den 1 KB EEPROM. Beim T4-Plus reicht der Flash-Bereich und ich nutze DATA_FLASH stattdessen, weil das Self-Programming auf dem ATmega328P stabiler läuft als die EEPROM-Erase-Write-Sequenz.
Diese Werte unterscheiden sich übrigens leicht von Board zu Board. Die Ri-Werte hängen an den konkreten Innenwiderständen der MCU-Ausgangsstufen, C0 und R0 an den Probe-Leitungslängen, Vref am internen Bandgap. Wer die Hex eines anderen Geräts mit dessen Flash-Region 1:1 auf sein eigenes flasht, übernimmt also fremde Kalibrierdaten, die zu falscher Mess-Anzeige führen können. Lieber einmal selbst kalibrieren.
3D-gedrucktes Gehäuse statt nackte Platine
Das Original-T4-Plus kommt ohne Gehäuse, nur die nackte Platine. Für den TC1 gab es ja damals zumindest noch eine billige Plastik-Halbschale, hier ist nicht mal das dabei. Auf Makerworld liegt ein passendes Modell von „LeoNerd“ mit der ID 1891431, „Case for LCR-T4 Component Tester“. Drei Teile: Unterschale, Frontblende mit ZIF-Sockel-Ausschnitt und Display-Fenster, Batterie-Klappe.
PETG, 0.2 mm Schichthöhe, fertig auf der Druckplatte. Drei Teile, kein Support nötig.
Ich habe das auf meinem Bambu Lab X1 Carbon in PETG ausgedruckt. PLA ginge auch, aber PETG ist hier ein bisschen weniger spröde, der Tester wird ja immer wieder mal in die Hand genommen. Maße passen direkt, das PCB sitzt sauber zwischen den Stegen, das Display fluchtet, der Button schaut zentrisch durch die Öffnung. Den 9V-Block fixiert die Klappe von hinten.
Finaler Funktionstest im Gehäuse
Boot-Banner „Component Tester v1.56m“ im 3D-gedruckten PETG-Gehäuse. Knopf drücken, Display bleibt an, alles, was es braucht.
„Bat 9.61V ok / Probing…“, der BAT_DIVIDER mit 10k zu 3.3k stimmt und eine frische 9V-Batterie wird korrekt erkannt.
Ein paar Testmessungen mit Bauteilen aus der Schublade: 10k-Widerstände, ein paar 100 nF Kondensatoren, ein BC547 und ein paar LEDs. Alle Werte plausibel, BC547 wird mit korrekter Pin-Zuordnung als NPN-Transistor erkannt, hFE in der erwarteten Größenordnung. Damit ist das Gerät einsatzbereit.
Die finale Konfiguration zum Mitnehmen
Damit andere mit dem gleichen 91make-Klon nicht die gleichen drei Tage verbrennen müssen, hier alle Änderungen relativ zur unveränderten m-firmware 1.56m an einer Stelle gesammelt.
Makefile (Auszug, nur die geänderten Zeilen):
MCU = atmega328 # NICHT atmega328p, sonst greift der Include-Guard nicht
FREQ = 8 # 8 MHz Quartz auf der v2-Variante, nicht 16
PARTNO = m328p # avrdude-Part bleibt m328p
Vier Punkte, die ich beim nächsten Klon-Tester sofort prüfen werde, statt wieder Stunden in der Diagnose zu verbringen:
Quartz mit der Lupe lesen bevor man die Frequenz im Makefile setzt. Identische PCB-Bezeichnung garantiert nicht den gleichen Takt. Bei diesem T4-Plus ist es 8 MHz, bei meinem ersten waren es 16 MHz. Zwei Boards, derselbe Aufdruck, verschiedene Bestückung.
ST7565R komplett schwarz nach erstem Flash ist fast immer ein zu hoher Bias und kein toter Controller. Erst FLAG_RATIO_65 auf FLAG_RATIO_55 oder FLAG_RATIO_45 ändern, dann weiter denken.
Silkscreen-Labels glauben, aber verifizieren. Auf dem v2-Board sind mis und mosi physisch vertauscht. Einmal Durchgangsprüfung gegen den MCU-Pin spart eine Stunde Frustration.
Vermeintliche Hardware-Fehler sind manchmal Build-Parameter. Ein Tester, der sich beim Loslassen ausschaltet, sieht aus wie eine kaputte Latch-Schaltung. War aber in Wirklichkeit nur die falsche CPU-Frequenz im Makefile, was den Boot-Code langsamer laufen ließ, als das mechanische Button-Zeitfenster es zuließ.
Repo und Quellen
Wie beim TC1 habe ich auch hier ein kleines Repo mit der fertigen Hex, den Config-Patches und einer README mit Schritt-für-Schritt-Anleitung gepackt: github.com/Kernel-Error/t4plus-v2-firmware-update. Lizenz folgt der m-firmware (EUPL v1.2), die Config-Patches sind als unified diff gegen die unveränderte 1.56m beigelegt.
Auf dem LCD steht „OSSC fw. 1.08a, 2014-2023 marqs“. Wenn ich ehrlich bin: dieses Banner zeigt mir das Gerät seit Ewigkeiten, ich war einfach nie in der Stimmung das mal aufzuräumen. „Läuft ja“ hat sich da über die Jahre breit gemacht. Seit 1.08a sind inzwischen viele Releases erschienen, der Sprung von 1.10 bis 1.21 hat eine Menge mitgebracht: Lumacode, Shadow-Mask-Presets, ein komplett neu geschriebenes SD-Profil-Handling und ein Stück mehr Display-Kompatibilität. Und ab 1.20 funktioniert sogar das Update selbst endlich vernünftig. Also Zeit, das mal sauber durchzuziehen.
Wer den OSSC nicht kennt: kurz vorweg, warum das Teil bei mir seit Jahren auf dem Tisch liegt und nicht im Karton.
Was ist der OSSC eigentlich?
Der Open Source Scan Converter (OSSC) ist ein FPGA-basierter Line-Multiplier von Markus „marqs“ Hiienkari. Schaltpläne und Firmware liegen komplett offen auf github.com/marqs85/ossc. Auf dem Board sitzt ein Altera Cyclone IV, der analoges Video von Retro-Konsolen und Computern aufnimmt und digital per HDMI wieder ausspuckt. SNES, Mega Drive, N64, PS1/PS2, Saturn, Dreamcast, Amiga, Neo Geo, frühe PCs mit VGA, der C64 über entsprechende Adapter, alles was RGB, Component oder Composite/S-Video raushaut, kommt rein.
Der eigentliche Trick ist nicht das Skalieren an sich, sondern wie der OSSC skaliert. Er arbeitet Zeile für Zeile und benutzt keinen Frame-Buffer. Eine eingehende Scanline wird sofort mehrfach (Line2x, Line3x, Line4x, Line5x) ausgegeben, das war’s. Geräte wie der Framemeister scalen über einen kompletten Frame-Buffer und addieren dadurch im Worst Case einen ganzen Frame Latenz oder mehr. Der OSSC liegt im Bereich weniger Mikrosekunden plus den Pixel-Delay des Displays. Auf einem ordentlichen 1080p- oder 4K-Monitor sieht ein 240p-Konsolensignal damit pixelgenau scharf aus, und das ohne dass sich der Controller anfühlt als hätte er einen halben Sekundenschlaf eingelegt.
Pro Konsole lassen sich Sample-Modi und Custom-Profile abspeichern, dazu kommen optionale Scanline-Simulation und seit den neueren Firmwares Shadow-Mask-Presets, also so eine Art simulierter Lochmasken-Look wie auf einer alten Trinitron-Röhre. Mein Gerät ist eine Hardware-Revision v1.6 mit Audio-Support im roten Acrylgehäuse, also nehme ich die -aud-Variante der Firmware. Mehr dazu gleich beim Flashen.
Auf der Oberseite lesbar: AV1-SCART-IN für RGB-Signale per SCART, AV2-YPBR-IN für Komponenten-Video oder VGA über einen entsprechenden Adapter, AV3 IN als optionaler Composite/S-Video-Eingang. Daneben der HDMI-Out (DVI-kompatibel, mit Audio auf meiner Revision), zwei Taster BTN0 und BTN1 für Navigation ohne Fernbedienung, die JTAG-Pins für Bastler und der für den Update-Vorgang interessante mSD-Slot.
Wofür ich das Ding eigentlich benutze
Bei mir landet der OSSC immer dann auf dem Tisch, wenn alte Hardware an einen modernen Bildschirm soll und dabei auch noch sauber auf dem PC aufgezeichnet werden muss. HDMI raus aus dem OSSC, in einen USB-HDMI-Grabber rein, fertig ist die Aufnahme. Das geht eben nicht nur für die offensichtliche Schiene 386er oder Spielekonsole. Auch ein alter Videorecorder, eine analoge Kamera die ich für jemanden repariere oder einfach mal eben auslesen muss, eine 8-Bit-Maschine die plötzlich wieder einen Use-Case bekommt, all das geht über denselben Weg ins Bild. Mein guter alter C64 hängt mit ein paar Handgriffen am OSSC und ist sofort auf dem 27-Zoll-Monitor zu sehen, statt umständlich einen kleinen Röhrenmonitor aus dem Schrank zu wuchten.
Zwei Beispiele aus meinem YouTube-Kanal, beide via OSSC aufgenommen, damit man sich vorstellen kann was am Ende rauskommt:
Was sich seit 1.08a getan hat
Zwischen meiner alten 1.08a und der aktuellen 1.21 hat marqs in mehreren Releases einiges nachgelegt. Die spannendsten Punkte aus den offiziellen Release-Notes in der Reihenfolge wie sie aufgetaucht sind:
1.10: Erste Lumacode-Unterstützung, HDMI-VRR-Flag, reduzierter Sampling-Jitter in den Optimized-Modes, MSX-Sync-Erkennung gefixt, neue High- und Optimal-Sampling-Raten für Passthru.
1.11: Lumacode auch für NES, 480p/576p im Line3x-Modus, Settings-Export wieder eingebaut, neue Display-Kompatibilitätsoptionen (ADC-/FPGA-PLL-Bandbreite, HPLL2x-Controls).
1.12: Lumacode auf Atari GTIA und VCS erweitert, HDR-Infoframe-Wiederholung gefixt, Default-ADC-PLL-Bandbreite reduziert für mehr Display-Kompatibilität, Full-VSYNC-Bypass für MDA-Karten.
1.20: Volle FAT32/exFAT-Unterstützung für die SD-Karte, neues Profil-Format mit deutlich verbesserter Kompatibilität zwischen Firmware-Versionen, Shadow-Mask- und Lumacode-Presets laden und speichern direkt von SD, OSD-Cursor-Farbe wählbar, DIY-Latency-Tester und Panasonic-Hack wieder verfügbar, alternativer Firmware-Slot im internen Flash, 480p/576p-Pillarbox-Option für Widescreen-Displays ohne Aspect-Ratio-Control.
1.21: Lumacode-Support finalisiert, Profil-Speichern und -Laden über SD gefixt.
Für mich relevant: das neue SD-Profil-Handling und die paar Display-Kompatibilitätsschrauben. Lumacode ist eine andere Geschichte (ein Trick um Composite-only-Konsolen wie NES oder Atari VCS auf Luma-Ebene farbgetrennt einzulesen, dafür brauche ich aber spezielle Lumacode-Kabel und passe heute eher).
Pre-1.20 heißt: dd, nicht copy
Hier ist der Knackpunkt, an dem viele beim Update straucheln. Der Bootloader auf dem OSSC erwartet die Firmware ab Sektor 0 der microSD, also als rohes Disk-Image. Eine FAT32-Partition mit der .bin drin reicht ihm nicht. Erst ab Version 1.20 wurde der Update-Mechanismus umgebaut, danach genügt der simple Datei-Copy in ein /fw/-Verzeichnis auf einer FAT32- oder exFAT-formatierten Karte. Wer wie ich von 1.08a kommt, muss diesen Schritt einmal mit dd machen, und ab dem nächsten Mal ist die SD-Karte dann nur noch ein Datenträger und kein Bootloader-Trick.
Heruntergeladen habe ich ossc_1.21-aud.bin direkt vom v1.21 Release. Die Datei ist 391 KB groß. marqs liefert in den Releases selbst keine Prüfsumme mit, also habe ich nach dem Download lokal eine SHA256 gezogen, damit ich beim Schreiben weiß dass die Datei nicht unterwegs verstümmelt wurde:
Dann auf die microSD. Eine beliebige Karte tut es, idealerweise eine kleine die man nicht für etwas Wichtiges braucht, das Image überschreibt eh den kompletten ersten Bereich. dd ist gnadenlos, einmal das falsche Device erwischt und die Systemplatte ist Vergangenheit. Also vorher mit lsblk oder dmesg | tail sicher feststellen, welches /dev/sdX die SD-Karte ist. Bei mir hier /dev/sdc, aber das ist auf jedem System ein anderes Ziel.
Kurzer Reminder, weil das hier wirklich wehtut wenn man es verbockt: das of= zeigt auf das ganze Device, nicht auf eine Partition. Also /dev/sdc, nicht /dev/sdc1. Und nicht die Systemplatte erwischen, ich weiß ja nicht ob ich das oft genug schreiben kann.
Am Gerät
Karte raus aus dem Card-Reader, rein in den mSD-Slot am OSSC. Gerät einschalten, mit der Fernbedienung (oder den beiden Tastern am Gehäuse) durch das Menü zu Settings → Fw. update und einmal bestätigen. Der OSSC liest das Image direkt von der microSD, schreibt es ins interne Flash und meldet nach ein paar Sekunden Erfolg. Danach aus, microSD raus, wieder an. Im Bootscreen steht jetzt brav „OSSC fw. 1.21“, und das alte „2014-2023“-Banner ist weg. Kein Drama, keine Fehler, einfach erledigt.
Eine Sache die in den Release-Notes explizit erwähnt wird und auf die man sich einstellen sollte: Profile und Settings sind zwischen Firmware-Versionen nicht garantiert kompatibel. Bei dem Sprung von 1.08a auf 1.21 erst recht nicht. Alles was an Custom-Sample-Phasen, Modi und Per-Console-Tweaks gespeichert war, muss einmal neu konfiguriert werden. Ab 1.20 ist das neue Profil-Format dann deutlich stabiler und überlebt zukünftige Sprünge eher, das war ja Teil des Cleanups in dem Release.
Ab 1.20 wird’s bequem
Das nächste Update bekomme ich jetzt geschenkt. Eine FAT32- oder exFAT-formatierte microSD, ein Ordner /fw/ im Root, die .bin reinkopiert, Karte in den Slot, im Menü das Update starten. Kein dd, kein „war das jetzt das richtige Device“, keine Karte die ich danach erst neu formatieren muss damit andere Geräte sie wieder anfassen. Das einmalige Holperstück dd war also nur weil ich so lange mit der alten Firmware unterwegs war. Wer schon auf 1.20 oder 1.21 ist, kommt nie wieder in die Verlegenheit.
Fazit
Der Aufwand für so ein Firmware-Update ist überschaubar, der Effekt aber spürbar. Ein paar weniger Display-Quirks, ein wirklich brauchbares Profil-Handling und das gute Gefühl dass das Gerät auf dem aktuellen Stand ist, das ein Hobby-Entwickler aus Finnland inzwischen über zehn Jahre pflegt. Open Source Hardware in der Praxis: ein einzelner Mensch, ein offenes Repository, ein FPGA und eine kleine Community von Retro-Enthusiasten die das Ding am Leben halten. Genau die Sorte Projekt, die ich gerne unterstütze, sei es nur indem ich auch mal Bug-Reports oder Erfahrungen rausschicke.
Wer selbst einen OSSC zu Hause hat und noch auf einer Firmware vor 1.20 ist, dem kann ich nur raten: einmal die saure dd-Pille schlucken und auf 1.21 hochziehen. Ab dann ist Updaten so langweilig wie Datei kopieren, und genau so soll es ja sein.
Weiter geht es mit einer Lötstation. Wie immer: Das ist ein Werkzeug, das ich selbst einsetze. Es bedeutet nicht, dass es das Beste der Welt ist oder dass man damit sofort eine professionelle SMD-Reparaturwerkstatt eröffnen sollte.
Ende des letzten Jahres war ich auf der Suche nach einer kompakten Lötstation, die eine ordentliche Wattleistung hat und eine Kombination aus Lötstation und Heißluftstation bietet. Sie sollte aber nicht zu teuer sein. Einzelne Geräte hatte ich zwar schon verschiedene, aber gedacht war es eher für den mobilen Einsatz im Repaircafé. Die dortigen Reparaturen sind meist überschaubar.
Dennoch muss ich zugeben, dass mich diese Station tatsächlich überrascht hat. Preis/Leistung sind wirklich gut. Fun Fact: Die FritzBox-Reparatur habe ich mit genau dieser Station gemacht – einfach um zu testen, was geht – und ja, es ging, und das sogar wirklich okay.
Natürlich ist sie nicht mit einer großen professionellen Station von beispielsweise Weller zu vergleichen. Aber das ist auch gar nicht der Anspruch. Das Ding kostet aktuell auf Amazon knapp 130 €. Dafür bekommt man 6 verschiedene Lötspitzen, Lötzinn, Heißluft mit verschiedenen Aufsätzen, ein digitales Display und ach … schaut mal selbst: https://amzn.to/47zAAmr
Ich würde behaupten: Die meisten Hobbyreparaturen – selbst im Bereich SMD – lassen sich damit problemlos durchführen. Aber hey, das ist nur meine Meinung.
Das hier ist zugleich der Auftakt einer kleinen Beitragsserie unter dem Titel „Was hast du in deiner Elektronikwerkstatt?“. Vor allem nach dem Beitrag zur FritzBox wurde diese Frage mehrfach an mich herangetragen.
Um gleich Klarheit zu schaffen: Von einer „Elektronikwerkstatt“ kann bei mir keine Rede sein. Was du hier siehst, ist meine kleine „Healing-Bench“, ganz sicher keine vollwertige Werkstatt und ohne entsprechenden Anspruch. Ich repariere und bastle Elektronik aus reinem Hobby, und man kann sich daran vermutlich nicht unbedingt ein Beispiel nehmen. Aber hey, ihr habt gefragt und ich hab was zu erzählen.
Mein Werkzeug soll eins sein: funktionieren. Ich will mich nicht darüber ärgern, es soll mich nicht umbringen und bitte auch nicht die Welt kosten. Ja, vieles davon stammt tatsächlich von AliExpress.
USB-Kabeltester: mein Einstieg
Heute stelle ich dir einen USB-Kabeltester vor. Mittlerweile kommt fast jedes Gerät mit einem USB-Kabel, zum Laden oder für den Datenaustausch. Besonders mit USB-C hat sich die Vielfalt der Kabelstandards enorm vergrößert. Ich meine damit nicht nur Lade-Standards, Spannungen und Leistungen, sondern auch verschiedene Datenübertragungsmodi.
Früher, zu Zeiten von USB-A/B, war das noch eindeutig: Ein Kabel konnte so ziemlich alles, Laden oder Daten. Mit Micro-USB begann dann der Wandel: Viele Kabel taugen nur noch zum Laden und übertragen keine Daten mehr.
So oder so hast du sicher auch so eine Schublade zuhause, in der sich unzählige USB-Kabel sammeln. Ständig ziehst du eins heraus und fragst dich: „Kannst du Daten übertragen?“ Das Kabel schweigt. Und bei seltsamem Verhalten fragt man sich: „Hast du einen Kabelbruch?“ Auch hier bleibt das Kabel stumm.
Praktische Hilfe für den Alltag
Hier kommt der USB-Kabeltester ins Spiel: Unter 10 €, betrieben mit einer einzigen CR2032-Knopfzelle, und er passt praktisch auf jede USB-Variante, selbst Lightning.
Beide Kabelenden einstecken, Gerät einschalten, und die beschrifteten LEDs zeigen sofort, welche Leitungen im Kabel verbunden sind. Oder auch nicht. Wer einen Kabelbruch sucht, wackelt einfach am Kabel. Wenn eine LED ausgeht, ist der Fehler gefunden. Das Ergebnis wird nicht durch irgendwelche Kondensatoren verfälscht.
Im Lieferumfang ist auch ein kleines, verständliches Handbuch enthalten: Es erklärt übersichtlich, welche Pins und Adern wo liegen und welche Funktion sie jeweils haben.
Fazit
Mit dem USB-Kabeltester machst du dir den Alltag deutlich leichter. Schnelle Kontrolle, einfache Bedienung, preiswert und super praktisch. Perfekt für alle, die einfach Ergebnisse wollen, ohne viel Aufwand.
Heute eine kleine Geschichte zu meinem Milchkühlschrank. Ob das spannend wird? Da bin ich mir noch nicht so sicher.
Warum ein Milchkühlschrank?
In meiner Küche steht ein Kaffeevollautomat. Bei angeschlossener Milch kann er die gängigen Milchkaffeegetränke auf Knopfdruck zubereiten. Vor allem im Homeoffice trinke ich schon mal einen Kaffee mehr. Da räume ich die Milch nicht für jeden Kaffee raus und wieder rein. Damit sie mehr als einen halben Tag überlebt, braucht sie etwas Kühlung. Genau hier kommt der Milchkühlschrank ins Spiel.
Wie ein Peltierelement funktioniert
Solche kleinen Kühlschränke basieren auf einem thermoelektrischen Kühler, dem Peltierelement. Ein flaches Quadrat mit zwei Leitungen. Schließt man Strom an, wird eine Seite warm und die andere kalt. Das Modul erzeugt eine Temperaturdifferenz zwischen beiden Seiten.
Sagen wir, das Modul erzeugt immer 30°C Differenz. Bei 20°C Raumtemperatur wäre die kalte Seite bei -10°C. Aber die heiße Seite wird im Betrieb wärmer, weil dort zwei Wärmequellen zusammenkommen:
Wärmeübertragung von der kalten Seite (Peltier-Effekt): Der Peltier-Effekt transportiert Wärme von der kalten zur heißen Seite. Diese transportierte Wärme wird an der heißen Seite freigesetzt.
Joulesche Verlustwärme (Widerstandserwärmung): Beim Fließen des Stroms durch die Halbleiterelemente entsteht zusätzliche Wärme. Diese erhöht ebenfalls die Temperatur der heißen Seite.
Kurz gesagt: Man muss die heiße Seite kühlen, damit die kalte Seite auch wirklich kalt wird. Die wird allerdings nicht unendlich kalt, da wir nur einen Temperaturunterschied erzeugen können. Dieses Wissen wird später noch hilfreich sein.
Aufbau des Milchkühlschranks
Um das besser erklären zu können, habe ich eine kleine Zeichnung angefertigt:
Die dicke schwarze Linie an der Innenseite der Schaumstoffdämmung stellt eine Metallplatte dar, die die Innenseite des Kühlschranks bildet. Diese ist mit Wärmeleitpaste mit dem Aluminiumblock verbunden. Im Aluminiumblock befinden sich Temperaturfühler, die das Peltier-Modul bei der gewünschten Temperatur abschalten. Die kalte Seite des Moduls ist mit Wärmeleitpaste am Aluminiumblock befestigt, die heiße Seite mit einem großen Kühlkörper verbunden. Dieser vergrößert die Oberfläche, sodass die Wärme besser an die Umgebungsluft abgegeben werden kann. Meist ist zusätzlich ein kleiner Lüfter verbaut.
Selbst bauen oder kaufen?
Mit diesem Wissen können wir uns selbst einen Milchkühlschrank bauen. Ein oft verwendetes Peltier-Modul ist das TEC1-12706, das man im Doppelpack für ca. 10 Euro bekommt. Ein einfacher PC-Lüfter kostet nochmal 10 Euro. Für rund 50 Euro kann man sich so ein Ding zusammenbauen.
Warum ist das wichtig? Weil die fertigen Geräte für ca. 150 Euro verkauft werden. Wenn ich das für 50 Euro bauen kann, dann kostet es in der Massenproduktion in China noch weniger. Ja, ich kaufe nicht nur das Gerät, sondern auch die Bequemlichkeit. Aber so einfach ist das für mich nicht zu rechtfertigen. Es widerstrebt mir einfach.
Einen gebrauchten zu kaufen schien eine Option. Was soll ich sagen? Die Technik in solchen Geräten ist oft billig und nicht auf Langlebigkeit ausgelegt. Von denen, die ich bisher in der Hand hatte, hat keines länger als drei Jahre gehalten. Selbst gebraucht werden sie noch für 100 Euro angeboten. Nicht verhältnismäßig.
Vom Elektroschrott gerettet
Dann stand bei meinem Arbeitgeber plötzlich ein defekter Milchkühlschrank beim Elektroschrott. Natürlich habe ich nachgefragt, ob ich ihn „entsorgen“ darf. Kein Problem.
Und was hatte das Ding? Nichts Besonderes. Der Lüfter war gestorben, die passive Kühlung reichte nicht aus. Verbaut war ein einfacher 80×80 mm 12V PC-Lüfter. Den hatte ich noch in der Ersatzteilkiste. Lüfter getauscht, fertig. Zumindest bis zum Sommer.
Thermische Brücke beseitigt
Als die Temperaturen stiegen, wurde es im Kühlschrank nicht mehr richtig kühl, obwohl Lüfter und Peltierelement alles gaben. Ich habe das Gerät aufgeschraubt, weil ich vermutete, dass die Wärmeleitpaste nach knapp fünf Jahren trocken war.
War es die Wärmeleitpaste? Ja und nein. Die Paste war trocken, aber das allein war nicht das Problem. Wenn ihr euch die Zeichnung anschaut, sind euch vielleicht die Befestigungsschrauben (3) aufgefallen. Diese Schrauben sind aus Metall und verbinden den kalten Aluminiumblock direkt mit dem Kühlkörper. Eine klassische thermische Brücke. Ein Teil der Kälte wird direkt wieder in Wärme umgewandelt.
Ich habe die Löcher im Kühlkörper aufgebohrt und mit meinem 3D-Drucker Kunststoffbuchsen für die Schrauben hergestellt. Zusätzlich kleine Federn, die alles zusammendrücken, auch wenn sich das Aluminium durch die Temperaturdifferenz ausdehnt. Die thermische Brücke war damit unterbrochen. Danach war der Kühlschrank deutlich effizienter und verbrauchte spürbar weniger Energie. Warum der Hersteller das nicht von Anfang an so gemacht hat? Ich habe nur das Wort „Gewinnmaximierung“ im Kopf.
Elkos im Netzteil
Das verbaute Netzteil war nur gerade so passend für die benötigte Leistung. Wenn ein Netzteil immer bei 90 bis 100 Prozent Belastung arbeitet, gibt es irgendwann auf. Ich hatte noch ein HOUHUI-1206 im Regal, ein 12V 6A Gleichstromnetzteil. Billig, lag aber nur rum.
Hätte ich mal auf mein früheres Ich gehört. Sechs Monate später war der Kühlschrank wieder warm, LED am Netzteil aus. Das Chinanetzteil hatte den Geist aufgegeben.
So langsam bröckelte der WAF (Woman Acceptance Factor). Also Netzteil aufgeschraubt und reingeschaut. Die Elektrolytkondensatoren waren aufgebläht. Ein Klassiker. Elkos getauscht, fertig.
Den Strombedarf habe ich gemessen. Ich komme nicht an die 6A, aber bei 12V und 6A wären das 72 Watt. Ein Milchkühlschrank, der 24/7 mit 70 Watt läuft, ist auf Dauer auch zu teuer. Das behalte ich im Auge.
So viel zur Geschichte meines Milchkühlschranks. Ob ich am Ende doch einen neuen kaufe? Vielleicht. Aber bis dahin läuft mein reparierter wieder.
Einen guten Dokumentenscanner zu finden, der auch noch bezahlbar ist, kann schnell zu einer Herausforderung werden. Viele ältere Geräte verlieren nach kurzer Zeit den Support für das nächste Betriebssystem und funktionieren dann nicht mehr. Wenn der Scanner zusätzlich unter Linux reibungslos laufen soll, wird es noch spannender.
Vor vielen Jahren konnte ich mir günstig einen Fujitsu ScanSnap S1500 zulegen. Dieser Dokumentenscanner erfüllt genau meine Anforderungen: Er zieht mehrere Seiten über den automatischen Dokumenteneinzug (ADF) ein, scannt beidseitig, ist schnell und liefert eine gute Auflösung. Wenn ich ihn nicht brauche, lässt er sich genauso schnell zusammenklappen, wie er sich aufstellen lässt, und nimmt kaum Platz auf meinem ohnehin schon überladenen Schreibtisch ein. Ich nutze den Scanner, um meine Post, Rechnungen und andere wichtige Unterlagen zu digitalisieren. Anfangs lief dies noch über eine Windows-VM, da es lange keine wirklich einfache Software für Linux gab, die auf Knopfdruck Dokumente scannt, Texterkennung (OCR) anwendet und alles als durchsuchbares PDF abspeichert. Dieses PDF wandert dann automatisch in meine Nextcloud und hilft mir, Ordnung in meinen Unterlagen zu halten.
Vor etwa anderthalb Jahren stieß ich auf die Software VueScan. Zwar kostet sie etwas, aber für mich ist sie jeden Cent wert. Sie läuft nativ oder als Flatpak auf meinem Linux-System, bietet mehr Funktionen, als ich tatsächlich benötige, und unterstützt eine beeindruckend große Anzahl an Scannern. Sie scannt sogar mein Netzwerk nach anderen Geräten, so läuft auch mein Samsung-Multifunktionsdrucker problemlos damit. Was mich jedoch wirklich beeindruckt, sind die Menschen hinter der Software.
Soweit ich weiß, wird VueScan nur von zwei Leuten entwickelt. Sie reagieren extrem schnell auf E-Mail-Anfragen und bieten hervorragenden Support. Gestern ist die Anwendung zum ersten Mal abgestürzt. Ich konnte sie direkt wieder öffnen, und alles war in Ordnung. Da VueScan den Absturz jedoch selbst erkannte, öffnete sich sofort ein Dialog für einen Fehlerbericht. Das kennt man ja. Ich füllte den Bericht aus und schickte ihn ab. Heute hatte ich bereits eine E-Mail vom Entwickler im Postfach, der mir Unterstützung anbot und weitere Fragen zum Absturz stellte. Diese schnelle, persönliche Reaktion hat mich sehr positiv überrascht.
Klar, mir war bereits aufgefallen, dass VueScan sehr häufig und regelmäßig Updates erhält, aber dass der Entwickler so engagiert dahintersteht, beeindruckt mich wirklich. Das gibt mir ein gutes Gefühl. Die Software ist klasse, der Preis ist in Ordnung (ich habe die Professional-Version), und der Support sowie die Reaktionszeit sind erstklassig. Außerdem unterstützen sie gefühlt jeden Scanner auf diesem Planeten. Und ja, die Software gibt es natürlich auch für Windows und Mac.
Ich muss also nur einmal lernen, wie eine Software funktioniert, und bin dann in der Lage, auf verschiedenen Betriebssystemen und mit verschiedenen Geräten zu arbeiten. Ich möchte ja nicht Experte für x verschiedene Softwarelösungen werden, sondern einfach nur schnell meine Dokumente digitalisieren.
Ich bekomme für diesen Beitrag keinerlei Vergütung oder Ähnliches, ich bin einfach wirklich überzeugt von VueScan. Probiert es doch einfach mal aus, und ich bin gespannt, ob ihr meine Meinung teilt.
Eigentlich sollte die Überschrift heißen: Ärgere ich mich gerade über mich selbst oder über AVM?
Zuhause arbeitete eine FRITZ!Box 7590 KA, die zu Beginn mit einem Frixtender erweitert wurde. Nach knapp zwei Jahren habe ich bemerkt, dass die FRITZ!Box angefangen hat zu fiepen. Eine Funktionseinschränkung konnte ich jedoch nicht feststellen. Da es aber knapp vor dem Ablauf der Garantie war, habe ich Kontakt mit dem AVM-Support aufgenommen.
Dem AVM-Support habe ich in einer kurzen E-Mail geschildert, dass meine Box plötzlich fiept und ob ihnen in diesem Zusammenhang vielleicht Probleme, beispielsweise mit Spulen oder Spannungsreglern, bekannt sind. Die Antwort vom AVM-Support ließ nicht lange auf sich warten und lautete zusammengefasst: „Nein, uns sind keine Probleme bekannt, aber du kannst deine Box gerne zur Überprüfung/Austausch einschicken.“
Jetzt kommen wir zum Punkt, warum ich mich ärgere und unschlüssig bin, ob ich mich über mich selbst oder über AVM ärgere. Für meine Arbeit benötige ich eine funktionsfähige Internetverbindung. Wenn ich die Box einschicke, muss ich für eine Alternative sorgen. Wenn AVM die Box vorsorglich gegen eine neue tauscht, wäre das zwar schön, aber es gibt schon zu viel Elektroschrott. Elektronik darf Geräusche machen. Spulen könnt ihr euch oft wie eine Art Schwungrad vorstellen. Es braucht etwas, um anzulaufen, läuft dann aber auch noch einige Zeit weiter, selbst wenn es niemand mehr antreibt. Das hängt mit den aufkommenden Magnetfeldern zusammen und ist so gewollt. Magneten kennt ihr, und dass dort Kräfte an den Bauteilen ziehen, könnt ihr euch jetzt ebenfalls vorstellen. Eine Spule kann also mit der Zeit anfangen, leichte Geräusche zu machen, und das ist auch okay. Für Spannungsregler gilt das ebenfalls. Stellt euch einfach euren Wasserhahn vor: Wenn ihr ihn voll aufdreht, kommen da vielleicht 5 Liter in der Minute heraus. Wenn ihr weniger Wasser wollt, macht ihr den Hahn ganz schnell an und wieder aus. Wie schnell ihr das Wasser ein- bzw. ausschalten müsst, um beispielsweise nur 1 Liter pro Minute fließen zu lassen, messt ihr mit euren Augen. Ganz grob funktionieren Schaltnetzteile so. Je nach Last kann man da also schon mal etwas hören, und das ist okay.
So ist ein weiteres Jahr ins Land gegangen, bis mir in einem meiner Newsticker die Meldung über sterbende FRITZ!Boxen vom Typ 7590 aufgefallen ist. Hier wird von anfänglichem Fiepen, schlechter werdendem 2,4-GHz-WLAN bis hin zum Totalausfall des WLANs und der Box berichtet. Bääähhhhh. Das klang verdächtig nach dem von mir beobachteten Fehlerbild. Nun ist meine Box aus jeglicher Garantie und Gewährleistung heraus. Den AVM-Support brauche ich also nicht mehr zu bemühen, sondern kann mich vielmehr mit dem Gedanken anfreunden, eine neue Box zu kaufen, um auf einen Ausfall vorbereitet zu sein. Zeitgleich haben bei uns im Ort die Arbeiten am Glasfaserausbau begonnen. Diese gehen so schnell und gut voran, dass ich damit rechnen kann, bis zum Ende dieses Jahres von DSL auf Glasfaser wechseln zu können. Mit diesem Wechsel kommt vom Anbieter auch eine neue FRITZ!Box. Tjo… Also Risiko eingehen oder eine Box kaufen, die in 5 oder 6 Monaten dann wohl irgendwo im Regal Staub fängt?
Bevor es eine Antwort auf diese Frage gibt, noch schnell zum Punkt mit dem Ärgern: Ich habe AVM bewusst gefragt, ob es bekannte Probleme mit der Box gibt und speziell auf die aus meiner Sicht verdächtigen Bauteile hingewiesen. Die Antwort war ein klares Nein. Das muss ich jetzt einfach so glauben, aber ich werde den Beigeschmack nicht los, dass es zum Zeitpunkt meiner Supportanfrage schon einige Reklamationen wegen dieses Problems gegeben haben müsste. Daher wohl mein möglicher Ärger über AVM – und dass ich auf die Möglichkeit eines Austauschs verzichtet habe – und der Ärger über mich selbst.
Habe ich jetzt eine neue Box gekauft oder nicht? Nein, habe ich natürlich nicht. Ich habe meine Box von der Wand genommen, aufgeschraubt und durchgemessen. Ja, Geräusche und etwas zu hohe Spannung für das 2,4-GHz-WLAN habe ich gemessen bzw. zuordnen können. Alles aber noch im Rahmen, sodass ich gehofft habe, dass es noch ein paar Monate gutgeht. War leider nicht so. Vor ein paar Wochen ist die Box an der Wand „geplatzt“ und ich musste in den sauren Apfel beißen und eine neue für den Übergang kaufen. Jetzt habe ich wohl ein Backup für die Zukunft. Woohoo 🙁 Manchmal lerne ich nicht so schnell dazu, oder? Naja, manchmal kommt halt eins zum anderen.
Ob meine alte Box wirklich mit genau dem beschriebenen Problem ausgefallen ist, wollte ich dennoch herausfinden. Die Sichtprüfung war noch immer gut, aber es war keine Spannung mehr zu messen. Daher habe ich mir von Aliexpress ein paar MP1477 (die genaue Bezeichnung ist MP1477GTF-Z) zuschicken lassen. Ich habe direkt alle drei verbauten Chips ausgetauscht und siehe da, die Box lebt wieder. Oft sollen dabei wohl noch die RF FRONT ENDs 055F als Folge der zu hohen Spannung sterben, aber diese haben es bei mir zum Glück überlebt.
Nun habe ich also auch noch ein Backup für das zukünftige Backup. Super…
Da ich bei Aliexpress insgesamt 10 Stück bestellt habe, liegen hier jetzt noch ein paar herum. Ich wäre bereit, sie gegen ein Snickers zu tauschen, falls jemand von euch vor einem ähnlichen Problem steht. Uhh, und bedenkt bitte, dass die Dinger ECHT klein sind. Ich habe euch mal einen auf ein 1-Cent-Stück gelegt. Ohne Heißluftstation und etwas SMD-Löterfahrung solltet ihr das vielleicht lieber nicht angehen.
Die Messpunkte und die erwarteten Spannungen findet ihr im folgenden Bildchen.
Seit gut zwei Jahren druckt bei mir ein QIDI i-Mate S. Damals gesucht: kompaktes Design, beheizbares Druckbett, geschlossener Druckraum, Druckbett nur in der Z-Achse, PLA/ABS/PETG. Gefunden, bestellt, seitdem im Einsatz.
Der Drucker tut, was er soll. Für den Preis in guter Qualität. Die Slicer-Software QIDI Print basiert auf Cura, ist aber speziell auf den Drucker angepasst. Soweit findet man das in jedem Testbericht. Was dort meistens fehlt: Infos zu Upgrades, dem Support und den kleinen Macken im Alltag.
Support
Der Support von QIDI war bisher durchgehend exzellent. Per E-Mail direkt an mateb@qd3dprinter.com kam immer innerhalb von 24 Stunden eine Antwort. Auch an Wochenenden und Feiertagen. Freundlich, hilfsbereit, mit Videos, Anleitungen und angepassten Konfigurationsdateien. Dateiaustausch lief unkompliziert über Google Drive. Wer schon einmal mit Herstellern hinter der chinesischen Firewall Daten austauschen wollte, versteht den Mehrwert.
All-Metal Hotend
Nach knapp einem Jahr kam das erste Upgrade: ein Full-Metal Extruder von AliExpress. Das passende Firmware-Update gab es direkt vom Support inklusive Anleitung. Einbau war einfach, besondere Einstellungsänderungen in QIDI Print nicht nötig.
Mit dem neuen Druckkopf war die Layerhaftung zunächst schlechter. Der Support half: Nicht jeder Schrittmotor läuft exakt gleich. Bei 2 cm Filamentvorschub kamen bei mir keine 2 cm. Drei E-Mails und 15 Minuten später hatte ich eine angepasste Konfigurationsdatei. Einfach „gedruckt“ und das Problem war Geschichte.
Schrittmotor-Kühlung
Die Schrittmotoren werden beim Druck spürbar warm. Nicht zu warm, aber warm genug, dass ich dem Drang nicht widerstehen konnte. Selbstklebende Kühlkörper von AliExpress auf alle Achsen-Motoren. Den Druckkopf-Motor ausgenommen, der wird bereits aktiv gekühlt und das zusätzliche Gewicht wäre kontraproduktiv.
Wer die passive Kühlung direkt aktiv machen will: Es gibt passende 24V-Lüfter dafür.
Filament Sensor
Filament bricht selten, aber es passiert. Oder es ist mitten im Druck leer und der Drucker läuft einfach weiter. Ein Filament Run Sensor von AliExpress erkennt das und stoppt den Druckvorgang. Filament nachladen, weitermachen.
Installation wieder einfach, wieder mit Anleitung vom Support und einer Konfigurationsdatei zum „Drucken“. Kleines Detail am Rande: In der deutschen Übersetzung der Firmware heißt der Filament Sensor „Glühfaden-Sensor“. Der Support hat sich über den Hinweis gefreut.
Bed Leveling
Automatisches Leveling gibt es nicht. Das geführte Leveling-Programm im Druckmenü funktioniert problemlos, die eigentlichen Muttern auch. Was nervt: die Sicherung mit einer zusätzlichen Flügelmutter. Man stellt alles perfekt ein, sichert die Muttern und dabei verschiebt sich der Abstand zur Nozzle wieder. Vielleicht habe ich zu dicke Finger.
Zusammen mit dem All-Metal Hotend bin ich auf eine Nozzle von Brozzl gewechselt. Beschichtetes Kupfer statt Messing: besserer Wärmeleitwert und etwas härter. Bei Messing und erst recht bei Stahl muss man die Temperatur 5-10 Grad höher setzen. Kupfer macht das überflüssig.
