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.
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.
Es gibt diese kleinen Bauteiltester aus China, die für 15 bis 20 Euro auf AliExpress oder Amazon rumschwirren. Der TC1, auch bekannt als LCR-TC1. Transistoren, Widerstände, Kondensatoren, MOSFETs, Dioden. Bauteil in den ZIF-Sockel stecken, Knopf drücken, fertig. Für den Preis eigentlich erstaunlich brauchbar. Aber die originale Firmware ist halt, sagen wir mal, solide Mittelklasse. Die Messgenauigkeit geht in Ordnung, aber nicht mehr, und die Zahl der erkannten Bauteile ist überschaubar. In der Open-Source-Welt gibt es zwei Firmware-Varianten für diese Tester: Die k-firmware als stabiles Original und die m-firmware von madires als aktiv weiterentwickelter Rewrite. Präzisere Messungen, mehr erkannte Bauteile, bessere IR-Protokollunterstützung, flexiblere Konfiguration und ein sauberes Menü mit Kalibrierung. Also habe ich mich drangesetzt.
Was als „schnell mal neue Firmware drauf“ geplant war, wurde ein mehrtägiger Abstieg in die Untiefen von STC-Microcontrollern, falschen Pinouts und parasitärer Stromversorgung. Aber der Reihe nach.
Was steckt im TC1?
Auf der Rückseite der Platine sitzen zwei Chips, die man kennen muss:
U1: ATmega324PA — der Hauptprozessor. Ein Atmel AVR im TQFP-44 Gehäuse, 32 KB Flash, 2 KB SRAM, 1 KB EEPROM. Hier läuft die eigentliche Tester-Firmware. Wird über ISP (In-System Programming) geflasht, also braucht man einen Programmer.
U4: STC15L104W — ein winziger 8051-kompatibler Mikrocontroller im SOP-8 Gehäuse von STC Micro. Der macht das Power-Management: Einschalten per Tastendruck, automatisches Abschalten nach Timeout. Klingt trivial, ist aber der Chip, der mir die meisten Kopfschmerzen bereitet hat.
Beide Chips brauchen neue Firmware. Die m-firmware liefert die Hex-Dateien für beide: ComponentTester.hex für den ATmega und u4.hex für den STC. Klingt einfach. War es nicht.
Erster Versuch: Backup der Original-Firmware
Bevor man irgendwas überschreibt, will man natürlich ein Backup. Gute Idee, klappt nur nicht. Die Lock Bits des ATmega sind auf 0xC0 gesetzt. Das bedeutet: Lesen des Flash-Inhalts ist gesperrt. Man kann die Firmware löschen und neu schreiben, aber nicht auslesen. Kein Backup möglich. Also Augen zu und durch.
U4 flashen: Der schwierigste Teil
Der STC15L104W hat einen eingebauten UART-Bootloader. Klingt praktisch. Man braucht theoretisch nur einen USB-TTL Adapter, sendet das Hex-File und der Chip programmiert sich selbst. Theoretisch. In der Praxis muss der Chip für den Bootloader einen sauberen Power-Cycle bekommen, also Strom weg, Strom wieder an. Und genau hier fängt das Drama an.
Im eingelöteten Zustand liegt VCC des STC über den Button-Schaltkreis auf GND. Der Bootloader startet schlicht nicht. Der Chip muss raus.
Also Atten ST-862D Heißluftstation raus, SOP-8 Chip bei 280°C vorsichtig von der Platine gehoben, Pads sauber gemacht. Zum späteren Wiedereinlöten dann die Sugon T3602. Für solche SMD-Arbeiten will man vernünftiges Werkzeug, mit einem 15-Euro-Lötkolben aus dem Baumarkt wird das nichts.
Der CH341 und seine 5V-Lüge
Erster Versuch: CH341 USB-TTL Adapter. Steht „3.3V“ drauf, also sollte das passen. Der STC15L104W ist ein 3.3V-only Chip, 5V auf den Datenleitungen wären sein Todesurteil. Also Multimeter dran, TX-Pin messen und… 5V. Auf dem TX-Pin. Trotz „3.3V“-Stellung. Der CH341 hat zwar einen 3.3V Spannungsregler für VCC, aber die Logikpegel auf TX bleiben bei 5V. Das steht nirgendwo auf dem Board, nirgendwo im Datenblatt des Adapters. Man muss es wissen oder messen.
Hätte ich nicht nachgemessen, wäre der STC jetzt Elektroschrott. Lektion gelernt: Immer nachmessen, nie dem Aufdruck vertrauen.
Also einen FT232RL USB-TTL Adapter bestellt. Der hat einen echten 3.3V/5V Jumper, der tatsächlich auch die Logikpegel umschaltet. Nachgemessen: TX bei 3.3V. Endlich.
Das Pinout-Desaster
Jetzt wirds peinlich. Ich habe stundenlang versucht, den STC über Pin 1 (P3.4) und Pin 3 (P3.5) anzusprechen. Keine Reaktion. Kein Bootloader. Nichts. Irgendwann habe ich nochmal das Datenblatt studiert und festgestellt: P3.4 und P3.5 sind GPIO-Pins. Die UART-Pins (RXD/TXD) liegen auf P3.0 und P3.1, also Pin 5 und Pin 6. Das SOP-8 Pinout:
Stunden. Am falschen Pin. Das sind so Momente, in denen man kurz aufstehen und was trinken gehen sollte. Keine Ahnung, warum ich die falschen Pins unbedingt wollte… Ich hab auf das Datenblatt geschaut und… na, vielleicht war die Brille dreckig, keine Ahnung. „Leider“ kamen da auch sinlose Daten bei zustande, was erst nach einer falschen Baudrate ausgesehen hat; vielleicht ist das eine gute Ausrede, warum ich da so lange hängen geblieben bin?!
Parasitäre Stromversorgung und der Breadboard-Aufbau
Das nächste Problem: Der STC-Bootloader braucht einen Power-Cycle zum Starten. Also VCC abziehen, Flash-Tool starten, VCC wieder anlegen. Sollte klappen. Tat es aber nicht zuverlässig. Warum? Der Chip versorgt sich über die TX/RX-Datenleitungen parasitär mit Strom. Selbst wenn VCC getrennt ist, reicht der Strom über die Schutzdioden in den I/O-Pins, um den Chip am Leben zu halten. Kein sauberer Power-Cycle, kein Bootloader.
Die Lösung: Beim Power-Cycle ALLE Drähte trennen, nicht nur VCC. Erst das Flash-Tool starten (wartet auf den Chip), dann alle Leitungen gleichzeitig einstecken. Dazu ein 220 Ohm Serienwiderstand auf der TX-Leitung als Schutz und ein 100nF Stützkondensator zwischen VCC und GND für eine stabile Versorgung.
Der Trick ist die niedrige Baudrate (-l 2400 für die initiale Kommunikation, -b 4800 zum Flashen) und das erhöhte Timeout (-t 12000). Zur Verifikation habe ich das Ganze nochmal mit STC-ISP v6.96S unter Windows (VirtualBox) gegengeprüft. Beides erfolgreich. Chip wieder eingelötet, weiter gehts.
U1 flashen: Der einfache Teil
Der ATmega324PA wird über ISP programmiert. Als Programmer dient ein ganz normaler Arduino Uno mit dem ArduinoISP-Sketch. Den lädt man in der Arduino IDE über File → Examples → ArduinoISP auf den Uno. Dann die Pins verbinden: MOSI (D11), MISO (D12), SCK (D13), RESET (D10) vom Arduino an den J4-Header auf der TC1-Rückseite, plus VCC und GND.
Auf der TC1-Platine gibt es ein J4-Pad für ISP. Ich habe da einen Pin-Header aufgelötet, das macht das Leben bei zukünftigen Updates deutlich einfacher. Dann mit avrdude:
Das ging durch. Erster Versuch. Nach dem STC-Drama fühlte sich das fast verdächtig einfach an.
„Kas Rh- _BB“ — Was zur Hölle?
Nach dem Flashen das Display eingeschaltet und… „Kas Rh- _BB“ statt „Bat 3.83V ok“. Die Zeichen sahen aus wie ein kaputtes Font-Rendering. Stundenlang habe ich nach SPI-Fehlern gesucht, den Display-Treiber hinterfragt (ST7735 vs. SEMI_ST7735), die Pin-Belegung dreimal geprüft. Nichts half.
Die Lösung war so simpel wie ärgerlich: „Kas“ ist der Anfang von „Kaseikyo“, einem IR-Protokollnamen. Die m-firmware speichert Strings standardmäßig im EEPROM (DATA_EEPROM in der config.h). Aber ich hatte nur die .hex-Datei geflasht, nicht die .eep-Datei fürs EEPROM. Die Firmware las also zufällige alte Daten aus dem EEPROM und interpretierte sie als Text.
Der Fix: In der config.h DATA_FLASH statt DATA_EEPROM setzen. Dann werden alle Strings direkt im Flash-Speicher abgelegt und man braucht kein separates EEPROM-Flashing. Nochmal kompiliert, nochmal geflasht. Uff… Bis ich darauf gekommen bin *kopfschüttel*. Zugegeben, darüber nachgedacht habe ich aber ich war mir fast sicher das in einem mit geflashed zu haben. Fast sicher halt. Eine Nacht darüber schlafen hat geholfen, klassisch also im Problem festgefressen.
Batteriespannung: 19V aus einer LiPo-Zelle?
Nächstes Problem: Das Display zeigte 19V Batteriespannung an. Der TC1 läuft mit einer einzelnen LiPo-Zelle, das sind 3,7 bis 4,2V. Die Standard-Konfiguration der m-firmware geht von einem Spannungsteiler auf der Batterieleitung aus (BAT_DIVIDER mit R1=10k, R2=3.3k für einen 9V-Block). Der TC1 hat aber keinen Spannungsteiler, die Batteriespannung geht direkt an den ADC.
Fix: BAT_DIRECT statt BAT_DIVIDER in der config.h. Dazu die Schwellwerte anpassen: BAT_WEAK=3400 und BAT_LOW=3100 (in mV) für eine einzelne LiPo-Zelle.
So soll das aussehen. 3.83V, alles ok.
Menü und Kalibrierung
Noch ein Stolperstein: Das Menü war nicht erreichbar. Die m-firmware hat verschiedene Wege, das Menü aufzurufen. Beim TC1 funktioniert das über UI_SHORT_CIRCUIT_MENU: Alle drei Probe-Pins im ZIF-Sockel kurzschließen und Start drücken. Dann öffnet sich das Menü mit Optionen für PWM, IR-Detector, Opto Coupler, Test und eben Adjustment.
Die Kalibrierung selbst ist einfach: Adjustment auswählen, mit leerem ZIF-Sockel starten, dann wenn gefordert einen Kurzschluss zwischen 123 einstecken. Die Firmware misst die internen Referenzen und speichert die Korrekturdaten. Dann den Kurzschluss wieder raus und es wird die Gegenprobe gemessen.
Die vollständige Konfiguration
Für alle, die das selbst machen wollen, hier die kompletten Änderungen gegenüber der Standard-Konfiguration der m-firmware (ComponentTester v1.56m):
Makefile:
MCU = atmega324p
FREQ = 16
config.h:
#define DATA_FLASH /* Strings im Flash statt EEPROM */
#define UI_AUTOHOLD /* Messergebnis halten bis Tastendruck */
#define UI_SHORT_CIRCUIT_MENU /* Menü über Kurzschluss aller Probes */
#define BAT_DIRECT /* Kein Spannungsteiler auf Batterie */
#define BAT_WEAK 3400 /* Warnung unter 3.4V */
#define BAT_LOW 3100 /* Abschaltung unter 3.1V */
config_644.h (Hardware-Mapping für den TC1):
/* Display: ST7735 über SPI Bit-Bang */
#define LCD_ST7735
#define LCD_RES PB4
#define LCD_DC PB5
#define LCD_SDA PB6
#define LCD_SCL PB7
#define LCD_FLIP_X
#define LCD_ROTATE
#define LCD_OFFSET_X 2
#define LCD_OFFSET_Y 1
#define LCD_LATE_ON
#define SPI_BITBANG /* SDA auf PB6 statt Hardware-MOSI PB5 */
/* Probe-Widerstände auf PORTC statt PORTD */
/* PC0-PC5 für die drei Probe-Paare */
/* Power und Button */
#define POWER_PORT PORTD
#define POWER_PIN PD2
#define BUTTON_PIN PD1
/* ADC-Pins vertauscht gegenüber Default */
#define TP_ZENER PA4
#define TP_REF PA3
Das Ergebnis
Component Tester v1.56m. Läuft.
Widerstände, MOSFETs, alles wird sauber erkannt. Die Werte passen.
Nach der Kalibrierung werden die Messwerte nochmal präziser. Vth 2065mV, Cgs 11.27nF, Rds 0.03 Ohm. Für einen 20-Euro-Tester absolut brauchbar.
Fazit und Quellen
War das ganze Prozedere nötig? Die originale Firmware funktioniert ja grundsätzlich. Aber wenn man sich auf die Messwerte verlassen will und nicht bei jedem unbekannten Bauteil rätseln möchte, lohnt sich der Aufwand. Die m-firmware liefert präzisere Ergebnisse, erkennt deutlich mehr Bauteile und hat ein richtiges Menü mit Kalibrierung. Und der J4-Header ist jetzt drauf, das nächste Firmware-Update ist dann tatsächlich in fünf Minuten erledigt.
Die fertige Firmware mit allen Config-Anpassungen für den TC1 und eine Schritt-für-Schritt-Anleitung habe ich auf GitHub gepackt. Da liegt auch die U4-Firmware (tc1-u4, GPL v3) und ein Verweis auf die m-firmware (EUPL v1.2).
Flugzeuge senden permanent ihre Position, Höhe und Geschwindigkeit auf 1090 MHz. Einfach so, unverschlüsselt, für jeden empfangbar. Das Ganze nennt sich ADS-B (Automatic Dependent Surveillance-Broadcast) und ist seit Jahren Standard in der Luftfahrt. Man braucht nur einen günstigen SDR-Empfänger und eine passende Antenne, um das Signal zu dekodieren. Und weil Dienste wie Flightradar24 auf Daten von freiwilligen Feedern angewiesen sind, bekommt man als Gegenleistung einen Business-Account, der sonst knapp 500 Euro im Jahr kostet.
Ich wollte das schon länger mal ausprobieren. Ein Raspberry Pi lag noch herum, ein billiger RTL-SDR-Stick war schnell bestellt, und die Antenne habe ich selbst gebaut. Nach längerem Betrieb kann ich sagen: Das Projekt macht erstaunlich viel Spaß und liefert faszinierende Ergebnisse. Bis zu 335 km Reichweite mit einer Antenne aus Kupferdraht und einer N-Buchse für unter 10 Euro.
Was ist ADS-B eigentlich?
ADS-B steht für Automatic Dependent Surveillance-Broadcast. Jedes moderne Verkehrsflugzeug sendet damit periodisch seine GPS-Position, Flughöhe, Geschwindigkeit, ICAO-Kennung und Squawk-Code auf 1090 MHz. Das Signal ist nicht verschlüsselt und nicht authentifiziert. Jeder mit einem passenden Empfänger kann es dekodieren. Der Empfang ist legal und rein passiv, man sendet nichts.
Die Reichweite hängt von der Sichtlinie (Line of Sight) ab. Flugzeuge in großer Höhe sind über hunderte Kilometer empfangbar. Tieffliegende Maschinen oder Flugzeuge hinter Bergen dagegen nicht. Topografie spielt eine große Rolle.
Warum ein eigener Feeder?
Flightradar24 lebt von den Daten freiwilliger Feeder weltweit. Je mehr Stationen, desto besser die Abdeckung. Als Gegenleistung gibt es einen kostenlosen Business-Account. Der kostet regulär knapp 500 Euro pro Jahr und bietet unter anderem erweiterte Filter, historische Flugdaten und eine werbefreie Oberfläche. Für Hardware im Wert von 100 bis 150 Euro ein ziemlich guter Deal.
Nebenbei kann man die empfangenen Daten auch parallel an andere Dienste wie FlightAware oder ADS-B Exchange schicken. Und natürlich ist es einfach ein tolles Bastelprojekt mit sofort sichtbarem Ergebnis. Man sieht in Echtzeit auf einer Karte, welche Maschinen gerade über einem fliegen.
Hardware
Das Setup ist überschaubar:
Komponente
Modell
Hinweis
Einplatinencomputer
Raspberry Pi 4 Model B
4 GB RAM, 64 GB SD-Karte
Betriebssystem
Pi24 (offizielles FR24-Image)
Debian Bookworm, Kernel 6.12
SDR-Dongle
Realtek RTL2838 (RTL-SDR)
Günstiger DVB-T-Stick als SDR-Empfänger
GPS-Dongle
VK-162 (u-blox 7)
USB, 3D-Fix, ~10 Satelliten
Antenne
Eigenbau: λ/4-Groundplane
Für 1090 MHz, siehe Abschnitt Antennenbau
Der Raspberry Pi 4 ist für die Aufgabe eigentlich überdimensioniert. Ein Pi 2 oder 3 würde ebenfalls reichen. Das Pi24-Image von Flightradar24 bringt alles mit: Betriebssystem, den Feeder-Client fr24feed, den ADS-B-Decoder dump1090 und ein lokales Web-Interface. SD-Karte flashen, WLAN oder Ethernet konfigurieren, fertig.
Der RTL-SDR-Dongle ist ein umfunktionierter DVB-T-Stick. Die Dinger kosten zwischen 10 und 25 Euro und können in einem breiten Frequenzbereich empfangen. Für ADS-B braucht man 1090 MHz, das schaffen die meisten RTL2832U-basierten Sticks problemlos.
Standort
Mein Feeder steht im Raum Bonn/Hangelar (Siegburg-Umgebung). Nicht gerade der ideale Standort für maximale Reichweite. Die Eifel im Süden blockiert einen Teil des Empfangs, und die Antenne steht aktuell nur am Fenster. Trotzdem sind die Ergebnisse beeindruckend, dazu gleich mehr.
Meine Radar-ID bei Flightradar24: T-EDKB55.
Antennenbau: λ/4-Groundplane für 1090 MHz
Die mitgelieferten DVB-T-Antennen sind für den Frequenzbereich um 500 MHz ausgelegt. Für ADS-B auf 1090 MHz sind sie schlicht ungeeignet. Ich habe drei verschiedene gekaufte DVB-T-Antennen getestet. Alle performten schlechter als die Original-Stummelantenne. Das war frustrierend, aber auch lehrreich.
Die Lösung: Selbst bauen. Nach einer hervorragenden Anleitung von weberblog.net habe ich eine λ/4-Groundplane-Antenne gebaut. Das ist im Prinzip ein vertikaler Strahler mit vier Radialen, abgestimmt auf 1090 MHz.
Die Physik dahinter ist simpel: Die Wellenlänge bei 1090 MHz beträgt λ = c / f ≈ 27,5 cm. Ein Viertel davon (λ/4) ergibt 68 mm. Das ist die Länge jedes Antennenelements.
Material:
N-Einbaubuchse (N-Flanschbuchse)
2,5 mm² Kupferdraht (massiv)
Koaxialkabel (RG213 oder Satellitenkabel)
M4-Schrauben zur Montage
Adapter je nach SDR-Stick (MCX, SMA oder BNC)
Aufbau: Ein Strahler (68 mm Kupferdraht) wird vertikal am Center-Pin der N-Buchse angelötet. Vier Radiale (ebenfalls 68 mm) werden an der Masse befestigt und ca. 45 Grad nach unten gebogen. Alle Elemente exakt auf 68 mm kürzen, das ist wichtig. Optional kann man einen Wetterschutz drüber stülpen, ein altes CD-Spindelgehäuse oder ein Stück PVC-Rohr tut es.
Laut der Bauanleitung von weberblog.net bringt die selbstgebaute Antenne im Indoor-Test +61% mehr erkannte Flugzeuge (39 → 63 Aircraft). Andere Bastler berichten von bis zu 160 NM Reichweite mit acht Radialen und Mastmontage. Meine Erfahrung bestätigt das. Der Unterschied zur Stummelantenne war sofort sichtbar.
Software
Das Pi24-Image bringt alles mit. fr24feed ist der offizielle Feeder-Client von Flightradar24. Er startet intern dump1090-mutability als ADS-B-Decoder und schickt die empfangenen Daten per UDP an die FR24-Server. Dazu läuft ein lighttpd für die lokalen Web-Interfaces.
Lokal gibt es drei Web-Interfaces: Die FR24 Status-GUI unter http://<IP>/, den JSON-Monitor unter http://<IP>:8754/monitor.json und die dump1090-Karte unter http://<IP>:8080/. Die Karte zeigt in Echtzeit alle empfangenen Flugzeuge auf einer OpenStreetMap-Karte. Das alleine ist schon faszinierend.
Ersteinrichtung
Nach dem Flashen des Pi24-Images musste ich noch ein paar Dinge anpassen:
Hostname geändert: pi24-bookworm → flightradar24
Statische IP konfiguriert via NetworkManager (DHCP → feste Adresse)
GPS-Koordinaten in fr24feed.ini eingetragen
dump978-fr24 deaktiviert (UAT 978 MHz wird in Europa nicht verwendet)
Bluetooth deaktiviert (nicht benötigt, erzeugte unnötige Fehlermeldungen)
OS-Update: 232 Pakete aktualisiert, Kernel von 6.6.21 auf 6.12.62
Nach drei Wochen Betrieb, noch mit der Antenne am Fenster:
Metrik
Wert
Flugzeuge aktuell getrackt (Snapshot)
74 (34 ADS-B + 40 Non-ADS-B)
Flugzeuge gesamt gesehen
1.541
Nachrichten verarbeitet
~8,9 Millionen
Maximale Reichweite
~335 km (~181 NM)
Signal (Durchschnitt)
-20,9 dBFS
SNR
~14,8 dB
CPU-Temperatur
47,2 °C
Uptime
20 Tage
335 Kilometer Reichweite. Mit einer Indoor-Antenne aus Kupferdraht für unter 10 Euro. Das war ein Norwegian-Flug (NOZ1802) über der Nordsee auf FL360. Das hätte ich vorher nicht für möglich gehalten.
Die Hauptabdeckung geht nach Norden und Nordwesten. KLM-Flüge über den Niederrhein und die Niederlande sind in 250 bis 335 km Entfernung problemlos sichtbar. Nach Nordosten reicht es bis ins Münsterland und den Raum Osnabrück. Nach Süden ist die Abdeckung durch die Eifel-Topografie eingeschränkt, aber Flüge bis in den Raum Trier/Luxemburg (~100 km) kommen noch durch. Lokal sieht man natürlich alles, was sich im Raum Bonn/Hangelar bewegt, Privatflieger, Kleinflugzeuge, Hubschrauber.
Ein paar Beispiele vom Snapshot:
Callsign
Airline
Höhe
Entfernung
NOZ1802
Norwegian
FL360
~335 km
BTI859
airBaltic
10.600 ft
~249 km
KLM96E
KLM
14.725 ft
~232 km
SIA314
Singapore Airlines
FL360
~25 km
BAW169
British Airways
FL330
~16 km
UAE62T
Emirates
FL380
~42 km
Singapore Airlines, Emirates und British Airways über dem Rheinland. Das hat was.
Bug: NTP-Client in fr24feed 1.0.55-0
Achtung, Falle: Version 1.0.55-0 von fr24feed ist defekt. Der Feeder bleibt in einer Endlosschleife mit [time][e]Failed to synchronize time hängen und geht nie online. Nicht nur MLAT funktioniert nicht, das gesamte Feeding ist tot.
Ich habe das mit strace und tcpdump analysiert. Der statisch kompilierte interne NTP-Client löst pool.ntp.org per DNS korrekt auf, sendet aber nie UDP-Pakete auf Port 123. Der Client ist schlicht kaputt. Kein Workaround hat funktioniert: weder Root-Rechte, noch CAP_NET_RAW, noch ein lokaler NTP-Server, noch nftables DNAT-Umleitung.
Die Lösung ist ein Downgrade:
# Downgrade auf funktionierende Version
sudo apt install fr24feed=1.0.54-0
# Version pinnen gegen Auto-Update
sudo apt-mark hold fr24feed
Ich habe den Bug direkt an den FR24-Support gemeldet, mit strace-Nachweis, tcpdump-Capture und der kompletten Liste getesteter Workarounds. Die Antwort war ernüchternd: Man könne den Bug nicht reproduzieren, vermutet aber eine Library-Regression durch einen Wechsel des Build-Systems. Der Bug ist seit Januar 2026 auch im FR24-Forum bekannt (Threads #186163 und #231707). Da fr24feed proprietär und Closed Source ist, kann man leider keinen Pull Request einreichen.
Das bedeutet auch: MLAT (Multilateration) funktioniert bei mir aktuell nicht. MLAT würde es ermöglichen, auch Flugzeuge ohne ADS-B-Transponder zu erfassen, indem mehrere Feeder-Stationen die Signallaufzeiten triangulieren. Dafür braucht der Feeder aber eine exakte Zeitbasis, und genau die liefert der kaputte NTP-Client nicht. Sobald FR24 eine gefixte Version veröffentlicht, werde ich das aktivieren.
Für 115 bis 155 Euro bekommt man einen funktionierenden ADS-B-Feeder und einen Flightradar24 Business-Account im Wert von knapp 500 Euro pro Jahr. Das Projekt amortisiert sich also ziemlich schnell.
Was noch kommt
MLAT aktivieren, sobald FR24 den NTP-Bug fixt
Outdoor-Montage der Antenne mit Wetterschutz, das sollte die Reichweite nochmals deutlich verbessern
Parallel-Feeding an FlightAware, ADS-B Exchange und andere Dienste
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.
Vor ziemlich genau 20 Jahren habe ich in einem Unternehmen gearbeitet, in dem Teile einer eigens entwickelten Lösung eine Zeit lang auf einem DALLAS DS80C400 basierten.
Der DALLAS DS80C400 ist ein hochintegrierter, netzwerkfähiger Mikrocontroller, der auf der Architektur des klassischen 8051 basiert. Entwickelt wurde er von Dallas Semiconductor (später Maxim Integrated) und war besonders für eingebettete Systeme geeignet, die eine Ethernet-Konnektivität benötigten.
Ja, klingt nicht weiter spannend, ich weiß – aber wir schreiben ja auch das Jahr 2025 und nicht 2005. Viele werden sich erinnern, dass der Raspberry Pi (Model B) im Februar 2012 veröffentlicht wurde. Arduino gab es zwar bereits seit 2005, aber ein einfach nutzbares TCP/IP-Netzwerk? Das war damals noch nicht so selbstverständlich. Der DS80C400 war mit seinem integrierten Netzwerkstack also ein ziemlich guter Mikrocontroller seiner Zeit.
Ich hatte ihn damals fertig montiert auf den Entwicklerboards von MAXIM in den Fingern. Das DSTINIM400 Embedded-Modul hatte 1 MB Flash, 1 MB SRAM, konnte 10/100 Mbit/s Ethernet, hatte zwei serielle RS232-Schnittstellen und noch ein paar andere nette Features. Dieses Modul steckte dann auf einem DSTINIS400, das – na ja, nennen wir es Hostboard – also eine Platine, die das DSTINIM400 aufnimmt und die verschiedenen Schnittstellen bereitstellt (Maxim TINI s400 Evaluation Board Socket).
Genau so ein Teil habe ich nun beim Aufräumen meiner „da muss ich noch mal nachschauen“-Elektronikkiste gefunden. Wirklich etwas damit tun wollte ich nicht, aber aus nostalgischen Gründen wollte ich es zumindest einmal booten sehen. Meine Erinnerung daran, wie das alles genau funktionierte, ist allerdings ziemlich verblasst. Irgendwas war da mit einer der beiden RS232-Schnittstellen und einem Terminalprogramm … also los.
Die mit Loader – Serial 0 beschriftete RS232-Schnittstelle war es, meine ich. Also habe ich mein Breakout-Board angeschlossen und ein bisschen herumgemessen. Sah soweit richtig aus – zumindest zeigte mein Oszilloskop beim Booten Aktivität auf den Datenleitungen. Die Pin-Belegung ist 1:1.
DSTINIm400 (DB9, DCE)
PC (DB9, DTE)
Funktion
2 (TXD)
2 (RXD)
Senden → Empfangen
3 (RXD)
3 (TXD)
Empfangen ← Senden
5 (GND)
5 (GND)
Gemeinsame Masse
Die Konfiguration der RS232 ist 9600 Baud, also 9,6 kbps. Dann noch 8N1:
8 Datenbits (8 Bits pro Zeichen)
N Paritätsbit (keine Parität)
1 Stoppbit
Da wirklich nur diese drei Leitungen benötigt werden, habe ich den Rest direkt beim Aufruf meiner Terminalemulation deaktiviert:
screen /dev/ttyUSB1 9600,cs8,-dtr,-rts
Hm … es passiert etwas, aber leider kommt nur Zeichensalat. Das spricht eher dafür, dass ich eine falsche Baudrate eingestellt habe. Also habe ich unterschiedliche Geschwindigkeiten ausprobiert – leider mit mehr oder weniger dem gleichen Ergebnis.
Vielleicht ist das auch der Grund, warum das Teil überhaupt in dieser Kiste gelandet ist?!
Ich wollte schon aufgeben, da fiel mir auf der Rückseite etwas auf: Ein MAX560CAI, ein Low-Dropout-Voltage-Regulator. In seiner direkten Nachbarschaft fehlen zwei Kondensatoren – C33 und C34. Klingt so, als wenn dort ein Keramik- oder Tantal-Kondensator für 10V und irgendwas zwischen 1 µF bis 10 µF hingehört. Und das könnte durchaus problematisch sein, denn einige Leitungen führen direkt bis zur RS232-Schnittstelle.
Um die richtigen Werte für die Kondensatoren zu finden, musste ich dann doch ein bisschen im Internet suchen. Dabei bin ich zumindest schon mal auf ein paar PDFs gestoßen, die ich hier mit euch teilen möchte.
Im DSTINIS-005-DSTINIS400.pdf bin ich dann zum Glück fündig geworden:
C10, C31, C32, C34-C36 → 1 µF
C33 → 10 nF
Passende SMD-Bauteile hatte ich zwar nicht (nicht gefunden), aber THT sollte für einen Test reichen. Für C33 habe ich einfach ebenfalls einen 1 µF-Kondensator genommen – das war mir passend genug für einen Versuch.
Noch ein Test mit 115200 Baud und … ha, er bootet!
TINI Slush OS v1.17 – man, man, man … lange nicht gesehen!
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.
Heute mal etwas ganz Einfaches… Beim Löten entstehen Dämpfe, die man besser nicht durch den „Lungenfilter“ aus der Luft ziehen sollte.
Hier kommen Lötdampfabsaugung ins Spiel. Es gibt kleine, einfache Modelle für etwa 50 €, die wie ein kleiner Tischventilator in der Nähe stehen, die Dämpfe absaugen und meist durch einen Aktivkohlefilter leiten. Allerdings stehen mir diese Geräte immer im Weg, und die Lüfter sind oft so schwach, dass trotzdem noch ein großer Teil der Dämpfe zu mir gelangt.
Da bei Projekten öfter mal Reste übrig bleiben, liegen in meinem Keller eigentlich schon alle Einzelteile für eine selbstgebaute Lötdampfabsaugung bereit. Man müsste sie nur noch zusammenbauen.
Ich habe noch einen 100-mm-Lüftungsschlauch aus Aluminium, der einigermaßen flexibel ist, einen 120-mm-12V-Lüfter, der für ordentlich Luftstrom sorgt, und ein paar 130-mm-Aktivkohlefilterplatten. Wenn ich davon einfach zwei doppelt nehme, geht mehr als genug Luft durch, und sie filtern die Dämpfe recht gut.
Mit FreeCAD habe ich dann ein Gehäuse für die Teile entworfen, das ich einfach unter meine Werkbank schrauben kann. So liegt nur der Schlauch in einer Ecke und kann bei Bedarf zur richtigen Stelle bewegt werden, um die Löt-Dämpfe direkt an der Quelle abzusaugen.
Hier ein paar Bilder für euch – die Druckdateien findet ihr bei Maker World.
Ob die Teile auch zu euren „Resten“ passen, müsst ihr selbst kurz prüfen.
