Hardware & Bauformen — was läuft, was geplant ist

[tostmann]

Überblick, welche Funk-Module RFNETHM trägt und in welchen Bauformen das Ganze läuft. Stand: v0.15.0.

Funk-Module (eine Variante anschließen)

Modul	Anschluss	Versorgung	Hinweis
HmIP-RFUSB (eq-3-Original)	USB-Host	5 V über USB	unmodifizierter Stick, eq-3-Firmware bleibt drauf
RPI-RF-MOD	40-Pin-Header	5 V auf Pin 2/4	eigener On-Board-LDO, kein 3V3-Pfad — 3,3 V auf Pin 1 lässt das Modul stumm
HM-MOD-RPI-PCB	40-Pin-Header	3,3 V auf Pin 1	BidCoS-only ELV-Modul, keine LEDs/BTN am Header

Der Funk-Teil bleibt immer der echte eq-3-Stack — RFNETHM ist reiner Transport.

Reset-Polarität (häufige Stolperfalle beim Eigenbau)

Modul	Reset-Pin (eQ3-Header)	Polarität
HM-MOD-RPI-PCB	Pin 12	active-LOW (0 = Reset, 1 = Run)
RPI-RF-MOD	Pin 35 (alt-Reset)	active-HIGH (1 = Reset, 0 = Run)

Keine externen Pull-Ups auf der RST-Linie — der MCU muss aktiv treiben. Volle Pin-Tabelle: docs/breadboard_wiring.md.

Bauformen

1. Devkit-Bringup (Stand heute, verifiziert):
ESP32-S3-Devkit mit nativem USB-OTG-PHY (z. B. YD-ESP32-S3 V1.4) + Pin-Header für den HM-Slot, auf dem Breadboard verkabelt. Beide HM-Modul-Familien und der USB-Stick laufen darauf live.

2. Eigenes PCB (in Planung):
ESP32-S3-MINI-1-N8 + W5500 (kabelgebundenes Ethernet) + USB-A-Buchse für den HmIP-RFUSB + 40-Pin-HM-Slot. Die GPIO-Auswahl im Devkit-Stadium ist schon so getroffen, dass die Firmware-Pin-Defines beim PCB-Übergang nicht geändert werden müssen. Hintergrund: docs/ethernet_addition.md.

3. Variante B — Klon-Brücke (separate Bauform, ohne ESP32):
CP2102N mit OTP-Brand 1B1F:C020, die sich gegenüber dem Host als HmIP-RFUSB ausgibt. Eigenständiger Pfad, nicht Teil der ESP32-Netzwerk-Adapter-Linie — und kein Umgehen der ECDSA-Sperre des Original-USB-Pfads.

Strom

5 V / ~200 mA reichen fürs Devkit + Modul. Wer RPI-RF-MOD nutzt, muss zusätzlich 5 V auf den HM-Header (Pin 2/4) durchziehen.

---

Zeig her, was Du gebaut hast — gerne mit Foto. Fragen zur Verkabelung unter Q&A.