IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Kategorie: Hardware & Reparatur (Seite 1 von 5)

Hardware-Tests, Reparaturanleitungen und Teardowns — von der Fritz!Box bis zum Bose-Kopfhörer.

NEXT Biometrics NB-2033-U: Reverse Engineering eines Fingerabdrucklesers für Linux

Illustration eines USB-Fingerabdrucklesers mit Linux-Tux und USB-Protokollanalyse (Reverse Engineering NB-2033-U)

Im letzten Beitrag zum Thema hatte ich angekündigt, dass ich mir auch den NB-2033-U vornehmen will. Der steckt in einem zweiten Fujitsu Notebook hier, dem von meiner Tochter Maja. Gleicher Hersteller, gleiche Sensorfamilie, sollte ähnlich laufen wie beim NB-2020-U. Dachte ich.

Falsch gedacht.

Hersteller sagt: geht nicht

Ich hatte bei NEXT Biometrics nach Protokolldokumentation oder einem SDK für den NB-2033-U gefragt. Kevin Hung, Director FAE, antwortete freundlich aber eindeutig:

„Both 2020-U and 2033-U have different firmware and USB stack. The code flow (libusb) related to 2033-U and 2020-U is different. This could be the reason for 2033-U failure/unsupported in linux. As of now, it is not supported.“

Kein SDK, keine Doku, kein Support. Und 74 Einträge auf linux-hardware.org mit Status „failed“ für die USB ID 298d:2033. Weltweit kein Linux-Support für dieses Gerät.

Gut. Dann eben Reverse Engineering.

Erster Versuch: Windows-Treiber belauschen

Plan A war klassisch: Windows-Treiber in einer VM laufen lassen, USB-Traffic mitschneiden. VirtualBox installiert, USB-Passthrough konfiguriert, Windows gestartet. Der Fingerabdruckleser tauchte im Gerätemanager auf. Mit Code 31. Treiber konnte das Gerät nicht starten. Secure Boot hatte VirtualBox den Kernel-Treiber nicht signiert, und der USB-Passthrough war damit unbrauchbar.

Plan A verworfen.

Plan B: Das SDK direkt auf Linux

Das SDK von NEXT Biometrics (libNBBiometrics.so) unterstützt den NB-2033-U intern. Es kommuniziert direkt über libusb, ohne Kernel-Treiber. Das heißt: ich kann das SDK-Sample direkt auf dem Linux-Notebook laufen lassen und gleichzeitig den USB-Traffic mit usbmon mitschneiden.

Dafür musste Secure Boot deaktiviert werden. usbmon ist ein Kernel-Modul, und lockdown=integrity (von Secure Boot gesetzt) blockiert es auch für root. Secure Boot im BIOS aus, lockdown=none in GRUB, Neustart. Danach:

modprobe usbmon
cat /sys/kernel/debug/usb/usbmon/3u > /tmp/capture.txt &
./NBBSample

7654 Zeilen USB-Traffic. Das komplette Protokoll des NB-2033-U, aufgezeichnet während einer Enrollment-Session.

Was dabei rauskam

Das Protokoll ist komplett anders als beim NB-1010-U/NB-2020-U. Kevins Aussage stimmte. Hier die wesentlichen Unterschiede:

EigenschaftNB-1010-U / NB-2020-UNB-2033-U
Bulk IN EndpointEP 3 (0x83)EP 1 (0x81)
Kommandoformat[0x80][CMD][SEQ][0x00]...[CMD][0x00][LEN_LO][LEN_HI][PAYLOAD] (TLV)
Finger-ErkennungEinzelnes 0x38Zwei 0x0D Config + 0x38
Bildübertragung90 Chunks à 540 Bytes180 Chunks à 268 Bytes
InitEinmal 0x07Zweimal 0x07 nötig

Gleicher Sensor-Die (256×180 Pixel, 385 DPI, aktiv thermisch), aber ein komplett anderer USB-Stack. Der NB-2033-U nutzt ein TLV-Format (Type-Length-Value) statt des festen Kommandoschemas vom NB-1010-U. Jedes Kommando hat eine eigene Längenangabe, und die Antworten sind anders strukturiert.

Die Kommandos im Detail

Aus dem USB-Capture konnte ich sechs Kommandos identifizieren:

  • 0x07 — Init/Wake. Muss zweimal gesendet werden, sonst reagiert der Sensor nicht.
  • 0x0D — Sensor-Konfiguration. Wird zweimal vor jeder Finger-Erkennung gebraucht, um den „Enhanced“ Modus zu aktivieren.
  • 0x38 — Finger-Erkennung. Byte 4 der Antwort ist der Detect-Level. Schwellwert 40.
  • 0x12 — Capture starten. Liefert 180 Zeilen à 256 Pixel, 8-Bit Graustufen.
  • 0x13 — Geräteinformationen (Hersteller, Modell, Seriennummer).
  • 0xF7 — Firmware-Version.

Thermischer Sensor: Eigenheiten

Der Sensor misst Temperaturänderungen, nicht statischen Kontakt. Das klingt nach einem Detail, ist aber für die Treiber-Implementierung entscheidend. Finger auflegen erzeugt einen kurzen Spike im Detect-Wert (10 bis 50+). Finger bleibt liegen, und der Wert fällt zurück auf Basisniveau. Der Treiber muss also den Spike erkennen, nicht einen dauerhaften Zustand.

Dazu kommt: Nach dem Init gibt es transiente Spikes, die ungefähr 1,5 Sekunden brauchen, bis sie abklingen. Ohne Settle-Pause nach dem Init erkennt der Treiber Phantom-Finger.

Der Treiber

Rausgekommen ist nb2033.c, ein eigenständiger libfprint-Treiber mit rund 350 Zeilen. Kein proprietärer Code, keine SDK-Abhängigkeit. Das SDK diente nur als Referenz für die Capture-Analyse, der Treiber ist sauber von Grund auf geschrieben. Lizenz: LGPL 2.1+ wie alle libfprint-Treiber.

Die State Machine:

  1. Init (0x07 × 2) mit 1,5 Sekunden Settle-Pause
  2. Finger-Detect-Polling (0x0D + 0x0D + 0x38, Schwellwert 40)
  3. Pre-Capture Config (0x0D)
  4. Capture (0x12) mit 150 ms Pause, dann 180 Zeilen lesen
  5. Bild an libfprint übergeben

Test

Getestet auf Majas Fujitsu Notebook mit Linux Mint 22.3:

$ fprintd-enroll
Using device /net/reactivated/Fprint/Device/0
Enrolling right-index-finger finger.
Enroll result: enroll-stage-passed
[... 5/5 Stages ...]
Enroll result: enroll-completed
$ fprintd-verify
Using device /net/reactivated/Fprint/Device/0
Listing enrolled fingers:
 - #0: right-index-finger
Verify result: verify-match (true)

Richtiger Finger: Match. Falscher Finger: No Match. Enrollment sauber, Verifikation zuverlässig.

Upstream

Der Merge Request ist eingereicht: MR !574 bei libfprint. Fünf Dateien: der neue Treiber, meson.build, autosuspend.hwdb und die Allowlist. CI läuft durch. Der verwandte MR !569 für den NB-2020-U ist noch in Review.

Für die Wiki-Aktualisierung (das Gerät von der „unsupported“ Liste nehmen) gibt es Issue #134.

Fazit

Der Hersteller sagt „not supported“, 74 Linux-User melden „failed“, und trotzdem war das an einem Nachmittag erledigt. SDK auf Linux ausführen, USB-Traffic mitschneiden, Protokoll rekonstruieren, Treiber schreiben, testen, upstream einreichen. Alles mit Open-Source-Tools: usbmon, libusb, libfprint.

Das Ergebnis: Majas Notebook hat jetzt einen funktionierenden Fingerabdruckleser unter Linux. Und sobald der Merge Request durch ist, haben ihn alle anderen auch.

Wie immer: Bei Fragen, fragen.

Quantis USB – Alter Quantenzufall aus der Schublade

Ich hatte noch einen Quantis USB in der Schublade liegen. Einen Hardware-Quantenzufallsgenerator von ID Quantique aus Genf. Ein Gerät, das echten Zufall erzeugt. Nicht pseudo, nicht algorithmisch, nicht „irgendwie aus Interrupts zusammengewürfelt“, sondern auf Basis von Quantenphysik. Fundamental unvorhersagbar.

Image of quantis usb

Nachdem ich in den letzten Beiträgen OpenSSH und Postfix/Dovecot mit Post-Quantum-Kryptografie abgesichert habe, fiel mir wieder ein: PQC schützt die Algorithmen vor Quantencomputern. Schön und gut. Aber was ist eigentlich mit der Zufallsquelle, die diese Algorithmen füttert? Zeit, das Teil mal wieder anzuschließen und zu schauen, was es taugt.

Was steckt in dem Gerät?

Der Quantis USB von ID Quantique ist ein sogenannter Quantum Random Number Generator, kurz QRNG. Das Prinzip dahinter: Ein Photonendetektor misst quantenoptisches Vakuumrauschen. Das sind Fluktuationen im elektromagnetischen Feld, die nach den Gesetzen der Quantenmechanik fundamental zufällig sind. Nicht „fast zufällig“ oder „praktisch zufällig“, sondern physikalisch beweisbar unvorhersagbar. Das ist ein wichtiger Unterschied zu allem, was ein Algorithmus je leisten kann. Dazu gleich mehr.

Das Gerät selbst ist fast schon enttäuschend simpel. USB 2.0 High-Speed, ein einziger Bulk-IN-Endpoint (0x86), 512 Bytes pro Read, rund 4 Mbit/s Durchsatz. Flashbare Firmware gibt es nicht. Die „Intelligenz“ steckt in der Optik und einem FPGA, nicht in Software. Das Ding macht genau eine Sache, und die macht es gut.

Mein Testgerät hat die Seriennummer 132244A410. Der Quantis USB ist inzwischen ein Legacy-Produkt, ID Quantique hat einen Nachfolger mit höherem Durchsatz im Programm. Einen öffentlichen Preis hatte das Gerät nie. „Request a Quote“, wie das bei Nischenprodukten mit Zertifizierungsanforderungen so üblich ist. Das Gerät ist METAS-zertifiziert und war für Kunden gedacht, die Common-Criteria-Anforderungen erfüllen müssen. Vergleichbare QRNGs bewegen sich im Bereich von 900 bis 2.000 Euro. Nicht gerade ein Impulskauf.

Einrichten unter Linux

Angeschlossen an mein Linux Mint 22.3 (Ubuntu 24.04 Basis) meldet sich das Gerät sofort im Kernel-Log:

$ dmesg | tail
usb 1-1: New USB device found, idVendor=0aba, idProduct=0102
usb 1-1: Product: Quantis USB
usb 1-1: Manufacturer: id Quantique
usb 1-1: SerialNumber: 132244A410

Kein spezieller Treiber nötig. Das ist ein generisches USB-Bulk-Device, der Kernel erkennt es und das war’s. Die proprietäre libquantis von ID Quantique kann man sich komplett sparen. Man kann direkt mit pyusb auf den Endpoint zugreifen. So mag ich das.

Damit das auch ohne Root funktioniert, legt man eine udev-Regel an:

# /etc/udev/rules.d/99-quantis.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="0aba", ATTR{idProduct}=="0102", MODE="0666", GROUP="plugdev", TAG+="uaccess"

Danach:

$ sudo udevadm control --reload-rules && sudo udevadm trigger

Gerät abstecken, wieder anstecken, fertig. Ab jetzt kann jeder Benutzer in der Gruppe plugdev auf das Gerät zugreifen.

Daten lesen mit Python

Zum Auslesen reicht das Paket python3-usb (pyusb). Installieren via apt install python3-usb, falls nicht vorhanden. Dann braucht man erstaunlich wenig Code:

import usb.core, usb.util

dev = usb.core.find(idVendor=0x0ABA, idProduct=0x0102)
dev.set_configuration()

cfg = dev.get_active_configuration()
intf = cfg[(0, 0)]
ep = usb.util.find_descriptor(
    intf,
    custom_match=lambda e:
        usb.util.endpoint_direction(e.bEndpointAddress) == usb.util.ENDPOINT_IN
)

data = ep.read(512, timeout=5000)
print(f"{len(data)} Bytes Quantenzufall gelesen")

Das ist alles. USB öffnen, Configuration setzen, den einen IN-Endpoint finden, 512 Bytes lesen. Fertig. Kein SDK, keine Bibliothek, kein Account, kein Cloud-Dienst. USB rein, Bytes raus.

Wichtig: Immer volle 512-Byte-Blöcke lesen (wMaxPacketSize). Wer weniger anfordert, bekommt USB-Overflow-Fehler. Das Gerät kennt keine halben Sachen. Es produziert kontinuierlich Zufallsdaten und schiebt sie in den USB-Puffer. Die müssen abgeholt werden, so wie sie kommen.

Für den Test habe ich das Ganze in eine Schleife gepackt und 100.000 Bytes gesammelt. Parallel dazu 100.000 Bytes aus /dev/urandom. Beide Datensätze dann durch dieselben statistischen Tests gejagt.

Der Test: Quantis vs. /dev/urandom

Jetzt wird’s spannend. Wie gut ist echter Quantenzufall im Vergleich zum Software-PRNG des Linux-Kernels?

Spoiler: Statistisch seht ihr keinen Unterschied. Und genau das ist der Punkt.

MetrikQuantis USB/dev/urandom
Shannon-Entropie7,998513 Bits/Byte7,998077 Bits/Byte
Maximum (theoretisch)8,0000008,000000
Effizienz99,9814 %99,9760 %
Chi² (Byte-Verteilung)205,8267,3
Erwartet (Chi²)~255 ± 23~255 ± 23
Bit-Balance (Anteil Einsen)49,975 %50,018 %
Serielle Korrelation+0,001230+0,003801
Längster Bit-Run (10 kB)15 Bits21 Bits
Erwarteter Run~16~16

Die Shannon-Entropie liegt bei beiden Quellen über 99,97 % des theoretischen Maximums von 8 Bit pro Byte. Das ist hervorragend. Die Chi²-Werte zeigen eine gleichmäßige Byte-Verteilung, beide liegen im erwarteten Bereich um 255. Die Bit-Balance ist nahezu perfekt bei 50/50, die serielle Korrelation praktisch null.

In den einfachen Tests schneidet der Quantis sogar minimal besser ab: niedrigere Korrelation, gleichmäßigere Verteilung, kürzerer maximaler Bit-Run. Aber ehrlich gesagt liegt das im statistischen Rauschen. Bei 100.000 Bytes Sample-Größe kann man keine belastbare Aussage über die Überlegenheit einer Quelle treffen. Man müsste Millionen oder Milliarden Bytes testen und Testsuiten wie die NIST SP 800-22 oder Dieharder durchlaufen lassen, um wirklich statistisch signifikante Unterschiede zu finden.

Heißt das, der Quantis ist überflüssig? Nein. Denn der Unterschied liegt nicht in der Statistik.

Wo liegt dann der echte Unterschied?

Die spannende Frage ist nicht, ob die Zahlen „zufälliger“ sind, sondern warum sie es sind.

/dev/urandom verwendet intern ChaCha20, einen deterministischen CSPRNG (Cryptographically Secure Pseudo-Random Number Generator). Der initiale Seed kommt aus der Kernel-Entropie: Hardware-Interrupts, Timing-Jitter, Geräte-Events, und seit einigen Jahren auch RDRAND/RDSEED aus der CPU, falls vorhanden. Das funktioniert in der Praxis hervorragend und ist extrem gut untersucht.

Aber es bleibt ein Algorithmus mit einem internen State. Wer diesen State kennt (und sei es nur theoretisch), kann alle zukünftigen Outputs berechnen. Das ist kein realistisches Angriffsszenario für euren Laptop. Aber es ist eine fundamentale Eigenschaft: Die Sicherheit von /dev/urandom basiert auf Berechnungsannahmen. Man nimmt an, dass ChaCha20 nicht effizient invertierbar ist. Stand heute stimmt das. Aber es ist eine Annahme, kein Beweis.

Der Quantis hingegen erzeugt Zufall aus Quantenvakuum-Fluktuationen. Da gibt es keinen Algorithmus, keinen State, keinen Seed. Die Unvorhersagbarkeit ist nicht durch die Komplexität eines Algorithmus geschützt, sondern durch die Gesetze der Quantenmechanik. Kein Angreifer, egal mit welcher Rechenleistung und egal mit wie viel Zeit, kann die nächsten Bits vorhersagen. Auch kein Quantencomputer. Das ist nicht berechnungstheoretisch sicher, sondern informationstheoretisch sicher. Die höchste Sicherheitskategorie, die es gibt.

Klingt akademisch? Zum Teil. Für den Alltag auf eurem Desktop oder Server reicht /dev/urandom völlig aus. Es gibt keinen bekannten praktischen Angriff darauf, und Linux‘ CSPRNG ist schnell, überall verfügbar und gut gewartet.

Aber es gibt Szenarien, in denen der Unterschied real zählt:

  • Erzeugung kryptografischer Schlüssel mit höchsten Sicherheitsanforderungen
  • Seeding von HSMs (Hardware Security Modules), die selbst keine eigene Entropiequelle haben
  • Regulatorische und Zertifizierungsanforderungen, also Common Criteria, FIPS-Validierung, BSI-Vorgaben
  • Wissenschaftliche Experimente, die physikalisch echten Zufall benötigen (z. B. Quantenoptik, Monte-Carlo-Simulationen)
  • Quantenschlüsselaustausch (QKD), ein Bereich in dem ID Quantique ebenfalls aktiv ist

Das größere Bild: QRNG und PQC

Post-Quantum Cryptography schützt kryptografische Algorithmen davor, von Quantencomputern gebrochen zu werden. ML-KEM für den Schlüsselaustausch, ML-DSA für Signaturen. Das ist die eine Seite der Medaille.

Die andere Seite ist die Zufallsquelle. Ein kryptografischer Algorithmus kann noch so quantensicher sein. Wenn der Zufall, mit dem Schlüssel erzeugt werden, vorhersagbar oder manipulierbar ist, hilft das alles nichts. Der Zufall ist das Fundament, auf dem alles andere aufbaut.

Ein QRNG schützt genau diesen Angriffsvektor. Beides zusammen, PQC-Algorithmen und eine quantenphysikalische Zufallsquelle, ergibt ein quantum-safe Gesamtsystem. Das ist heute für die meisten von uns Overkill. Aber die Bausteine existieren, sie sind verfügbar, und es schadet nicht zu wissen, wie sie funktionieren.

Übrigens: Wer jetzt denkt „dann stecke ich den Quantis in meinen Server und bin sicher“, der macht es sich zu einfach. Die Vertrauensfrage verschiebt sich nur. Woher weiß ich, dass das Gerät tatsächlich Quantenzufall liefert und nicht einfach einen internen PRNG hat? Bei einem zertifizierten Gerät wie dem Quantis gibt es dafür Prüfberichte. Aber Vertrauen in Hardware bleibt immer ein Thema. Das ist bei Intel RDRAND nicht anders.

Einbindung ins System

Für die Vollständigkeit: Der Quantis USB lässt sich über rng-tools (rngd) als zusätzliche Entropiequelle in den Kernel-Entropiepool einbinden. Für Server mit hohem Entropie-Bedarf, also TLS-Terminierung unter Last, Massenerzeugung von Schlüsseln oder VPN-Gateways, kann das sinnvoll sein.

Ich habe das auf meinem Desktop nicht gemacht. Brauche ich dort nicht. Aber die Möglichkeit steht im Raum, falls jemand von euch einen Quantis oder ein vergleichbares Gerät an einen Server hängen möchte.

Fazit

Ein alter Hardware-QRNG, ein USB-Port, ein paar Zeilen Python, und man hat echten Quantenzufall auf dem Tisch. Statistisch nicht unterscheidbar von /dev/urandom, aber fundamental anders in der Entstehung. Die Sicherheit kommt nicht aus einem Algorithmus, sondern aus der Physik. Informationstheoretisch statt berechnungstheoretisch. Ein Unterschied, der in den allermeisten Fällen keine praktische Rolle spielt. Aber ein verdammt eleganter.

Für euren Desktop braucht ihr das nicht. Aber verstehen, warum es existiert und wie es sich einordnet, gerade im Kontext von Post-Quantum-Kryptografie, das lohnt sich. Warum denke ich jetzt an CIA und MAD? ;-D

Wie haltet ihr es mit euren Zufallsquellen? Vertraut ihr blind auf /dev/urandom, oder habt ihr euch schon mal Gedanken über die Entropiequelle dahinter gemacht?

NEXT Biometrics NB-2020-U Fingerabdruckleser unter Linux zum Laufen gebracht

In meinem Fujitsu Notebook steckt ein Fingerabdruckleser. Ein NEXT Biometrics NB-2020-U, USB ID 298d:2020. Unter Windows funktioniert er, unter Linux nicht. Kein Treiber, kein Support, nichts. Das Gerät taucht in lsusb auf, wird aber von keinem Treiber erkannt. Im libfprint Wiki steht es auf der Liste der nicht unterstützten Geräte. Dort steht es schon eine Weile.

Das hat mich gestört.

Picture of NB-2020-U

libfprint kennt den NB-1010-U. Das ist ein externer USB Fingerabdruckleser von NEXT Biometrics, der seit einiger Zeit einen funktionierenden Treiber hat. Der NB-2020-U ist die eingebettete Variante desselben Sensors, gedacht für den Einbau in Notebooks. Wenn man sich Teardown Reports ansieht, etwa von System Plus Consulting oder Yole Group, dann stellt man fest: Beide Geräte verwenden den identischen Sensor Die. Gleiche Technik, anderes Gehäuse.

Das war der erste Anhaltspunkt. Wenn die Hardware gleich ist, sollte auch das USB Protokoll gleich sein. Und wenn das Protokoll gleich ist, sollte der vorhandene Treiber funktionieren.

Bevor ich aber einfach auf Verdacht losprogrammiert habe, wollte ich es absichern. Ich habe NEXT Biometrics direkt angeschrieben. Kevin Hung, Director FAE bei NEXT Biometrics, hatte mir bereits 2022 auf eine Anfrage zu Linux Treibern geantwortet. Damals war sein Vorschlag, über Fujitsu zu gehen. Das führte ins Leere. Diesmal habe ich konkret angeboten, selbst einen libfprint Treiber zu schreiben, und um das SDK gebeten.

Kevin hat mir daraufhin das NBBiometrics ANF SDK 3.0.0.1384 zugeschickt. Ein komplettes SDK mit Headern, Bibliotheken, Beispielcode und Dokumentation. Das war sehr hilfreich, denn die Header bestätigen einiges. Das SDK nutzt eine einzige Shared Library libNBBiometrics.so für alle Gerätetypen. Der NB-1010-U hat den internen Gerätetyp 200, der NB-2020-U den Typ 202. Beide verwenden dasselbe Scanformat: 180×256 Pixel bei 385 DPI. Die USB Vendor ID ist bei beiden 0x298d, nur die Product ID unterscheidet sich: 0x1010 beim einen, 0x2020 beim anderen.

Wichtig: Das SDK ist proprietär. Für den eigentlichen Treiber habe ich keinen Code daraus verwendet. libfprint akzeptiert nur sauberen, eigenständig entwickelten Code. Das SDK diente ausschließlich als Referenz, um die Protokollkompatibilität zu bestätigen.

Also habe ich es einfach ausprobiert. Den bestehenden nb1010.c Treiber genommen, die USB Product ID 0x2020 zur id_table hinzugefügt und gebaut. Dann auf dem Fujitsu Notebook getestet.

Es funktionierte sofort.

Geräteerkennung, USB Interface Claim, die State Machine für die Fingererkennung, alles lief auf Anhieb. fprintd-enroll hat Fingerabdrücke aufgenommen, fprintd-verify hat sie korrekt verifiziert. Der bestehende Treibercode brauchte keinerlei Anpassungen. Null. Nur die PID in der Tabelle und den Gerätenamen.

Ein Blick auf die USB Deskriptoren bestätigt das Bild. Der NB-2020-U hat exakt dasselbe Endpoint Layout wie der NB-1010-U: Bulk OUT auf Endpoint 0x02, Bulk IN auf Endpoint 0x83. Dazu kommt ein Interrupt Endpoint auf 0x81, den der Treiber nicht verwendet. Die Kommunikation läuft identisch ab.

Der Patch selbst ist entsprechend klein. Drei Dateien, drei Zeilen rein, drei Zeilen raus:

  1. libfprint/drivers/nb1010.c: Die neue PID 0x2020 wird in die id_table eingetragen und der full_name auf "NextBiometrics NB-1010-U/NB-2020-U" erweitert.
  2. data/autosuspend.hwdb: Der Eintrag 298d:2020 wird von der Liste der nicht unterstützten Geräte in die Sektion des nb1010 Treibers verschoben.
  3. libfprint/fprint-list-udev-hwdb.c: Der Eintrag wird aus der Allowlist der nicht unterstützten Geräte entfernt, da er jetzt vom Treiber abgedeckt wird.

Den Merge Request habe ich bei libfprint upstream eingereicht: MR !569. Die CI Pipeline läuft durch, alle 124 Tests bestehen. Jetzt heißt es warten auf das Review durch die Maintainer.

Für alle, die denselben Fingerabdruckleser in ihrem Notebook haben: Sobald der Patch gemergt und in einer neuen libfprint Version enthalten ist, funktioniert der Sensor out of the box. Enrollment und Verifikation über fprintd laufen sauber. Wer nicht warten möchte, kann den Patch auch jetzt schon selbst auf ein aktuelles libfprint anwenden.

Im selben Fujitsu Notebook meiner Tochter steckt ein NB-2033-U, ein weiterer Fingerabdruckleser aus der gleichen Familie. Der verwendet allerdings ein komplett anderes Protokoll und ließ sich nicht einfach mit dem nb1010 Treiber ansprechen. Den habe ich per Reverse Engineering geknackt.

OWON XDM1041: Firmware V4.7.0 (20220913) – Update-Dateien und Vorgehen

Ich nutze das digitale Multimeter OWON XDM1041.
Preis-Leistung passt für mich sehr gut. Das Gerät lässt sich per USB mit dem PC verbinden, Messwerte können ausgelesen und aufgezeichnet werden. Für meine Elektronik-Projekte an der Werkbank bringt es alles mit, was ich brauche.

Image of OWON XDM1041 digital multimeter with firmware version V4.7.0 (20220913)

Die Herstellersoftware funktioniert, ist aber klar auf Windows fokussiert. Unter Linux nutze ich stattdessen RustyMeter, eine saubere Alternative: https://github.com/markusdd/rusty_meter

Mein XDM1041 lief zunächst mit der Firmware V3.3.0. Auf der OWON-Webseite findet sich aktuell jedoch kein Firmware-Download für dieses Gerät. Nach Kontakt mit dem Support per E-Mail hat mir OWON freundlicherweise die aktuellste Firmware (Stand: 08.01.2026) zur Verfügung gestellt: XDM10412212508.zip (MD5 509766ba23eb008f32f60a82cddca08b)

Das ZIP-Archiv enthält:

  • eine PDF-Anleitung
  • USB-Treiber für Windows
  • die Software DS Wave zum Einspielen der Firmware
  • die beiden Firmware-Dateien:
    • OS--XDM1041_OS_V4.7.0_20220913.bin
    • TX-2212508.bin

Das Firmware-Update selbst ist unkompliziert und funktioniert exakt wie in der Anleitung beschrieben. Nach dem Update läuft das Gerät mit Firmware V4.7.0, im Display angezeigt als 20220913.

Der ursprüngliche Download von OWON war leider sehr langsam, brach mehrfach ab und erzeugte wiederholt TLS-Fehler. Ob das an Routing-Problemen oder an der sprichwörtlichen „chinesischen Mauer“ liegt, lässt sich schwer sagen.

Natürlich habe ich ebenfalls gefragt, ob ich das Firmware Update hier zum Download anbieten kann. Das geht aber leider nicht, denn es scheint jeweils für gewisse Geräte unterschiedliche zu geben:

Dear,
We can’t share the firmware updates as each one is exclusive to a specific device and not cross-compatible.

Ihr müsst also jeweils selbst auf den Support zugehen, E-Mail hat für mich gut funktioniert. Ich habe noch nach einem Kontakt über WeChat gefragt und nach einem Changelog. Sollte ich etwas bekommen, ergänze ich es hier.

Viel Erfolg beim Firmware-Update.

Siehe auch: Multifunktionstester für Bauteile

Preciva 992D+ im Test: Löt- und Heißluftstation für Hobby & Repaircafé

Picture of Soldering Station Preciva 992D+

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.

Fragen? Einfach melden.

USB-Kabeltester: Kabelbrüche & Datenfähigkeiten schnell prüfen

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.

USB Kabeltester mit leuchtenden LEDs und eingestecktem USB-C Kabel.

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.

Link zu AliExpress: https://s.click.aliexpress.com/e/_oBI7lsv

So funktioniert’s

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.

Fragen? Einfach melden.

PDS OSIcom-Office Box: Retro-PC mit JUMPtec SBC & SUSE Linux​

Vor etwas über 20 Jahren habe ich unter anderem mit OSIcom-office Boxen von PDS (Programm und Datenservice) gearbeitet. Dazu habe ich schon mal etwas geschrieben.

Picture of an PDS OSIcom-office Box

Zufällig bin ich dann in einem Onlineshop auf genau so eine OSIcom Box gestoßen, die dort zum Verkauf angeboten wurde. Der Preis lag deutlich über dem, was ich aus nostalgischen Gründen bereit wäre, dafür zu zahlen – aber ich habe einfach mal mein Glück versucht und per E-Mail ein Angebot unterbreitet. Und siehe da, der Verkäufer war einverstanden! Nun bin ich also Besitzer einer alten OSIcom-office Box. An dieser Stelle noch einmal vielen Dank an Wie-Tec für das Entgegenkommen.

Die Box basiert auf einem SBC (Single Board Computer) von JUMPtec. Das Modell scheint folgendes zu sein: 07029-0000-26-7. Im POST wird die BIOS-Version <LEU2R118> angezeigt. Hersteller: JUMPtec® Industrielle Computertechnik AG.

Verbaut sind ein Intel Pentium MMX 266 MHz, 256 MB RAM, eine 40 GB Festplatte, ein Diskettenlaufwerk, sowie eine Netzwerk- und ISDN-Karte. Der SBC steckt in einer ISA-Backplane. Das könnte sogar ein ziemlich guter Retro-DOS-Gaming-PC werden!

Spannenderweise war die Festplatte noch mit Daten gefüllt. Ob es sich dabei nur um eine Testinstallation oder echte Produktivdaten handelt, kann ich nicht bewerten. Überrascht hat mich das dennoch positiv, denn so konnte ich den kompletten Bootvorgang noch einmal genießen. Wobei – nicht nur ich:

Kernel 2.4.27 – man, ist das lange her! Grundlage ist ein altes SUSE Linux. Natürlich habe ich auch noch ein paar Bilder für euch angelegt.

Das BIOS konnte ich sichern, und zusammen mit den Bildern wird das sicher eine brauchbare Ergänzung für The Retro Web. Falls jemand von euch noch Handbücher oder ähnliches zur Hardware hat – ich würde mich sehr darüber freuen!

Siehe auch: Dallas DS80C400: 8051-Ethernet-Mikrocontroller neu entdeckt, Commodore Floppy Disk Preservation: Firmware-Bug im xum1541 gefunden und gefixt

Fragen? Einfach melden.

Dallas DS80C400: 8051-Ethernet-Mikrocontroller neu entdeckt

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.

Dallas TINI400 evaluation board with DS80C400 microcontroller

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.

DSTINIS-005-DSTINIS400.pdf
TINI_GUIDE.pdf
DSTINIm400.pdf
DSTINIm400EVKit.pdf

Im DSTINIS-005-DSTINIS400.pdf bin ich dann zum Glück fündig geworden:

  • C10, C31, C32, C34-C361 µF
  • C3310 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!

Siehe auch: PDS OSIcom-Office Box: Retro-PC mit JUMPtec SBC & SUSE Linux​

Milchkühlschrank: Mein DIY-Projekt mit Reparatur-Tipp

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:

Schematische Darstellung, der Funktion eins Peltier Milchkühlers.

1 Schaumstoffdämmung, 2 Kühlkörper, 3 Befestigungsschrauben, 4 Peltier-Modul, 5 Aluminiumblock

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.

Siehe auch: Multifunktionstester für Bauteile

Fragen? Einfach melden.

Lötdampfabsaugung selber bauen: DIY-Projekt mit 3D-Druck und Restteilen​

Heute mal etwas ganz Einfaches… Beim Löten entstehen Dämpfe, die man besser nicht durch den „Lungenfilter“ aus der Luft ziehen sollte.

3D-gedruckte Lötdampfabsaugung

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.

Dann gibt es noch Absaugungen mit mehr oder weniger flexiblem Schlauch. Auch hier erfolgt die Filterung ähnlich, aber diese Modelle kosten dann schnell ein paar Hundert Euro.

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.

Oh, Schlauch und Filter findet ihr bei Amazon.

Siehe auch: RD6006 Labornetzteil

Fragen? Einfach melden.

« Ältere Beiträge

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑