Serielle Schnittstelle überwachen, sniffen, debuggen und protokollieren

Auf dieser Seite lernst du drei Möglichkeiten kennen, die serielle Kommunikation zwischen Geräten (PC, Controller, Embedded-Boards) zu analysieren – und warum SerialTools COM Sniffer oft die beste Lösung ist: nur Software, keine Verkabelung, transparent und geeignet für Monitor/Sniffer/Debugger/Logger – auch über Tage hinweg.

Was dich erwartet

• Kapitel 1: was es bedeutet, einen COM-Port zu überwachen, wie Bytes/Bits aufgebaut sind und wie die serielle Schnittstelle sie sendet (Start/Daten/Parität/Stopp) sowie TX/RX und Baudrate.
• Kapitel 2: die klassische Methode des physischen Sniffens mit zwei USB↔Seriell-Adaptern: nur das RX an die TX-Leitungen der beiden Geräte anschließen und Masse verbinden. Ideal für einen einfachen Monitor/Logger.
• Kapitel 3: dasselbe Konzept, angewendet auf einen Master-PC, der über USB↔Seriell-/RS-232-/RS-485-Wandler mit einem Zielgerät kommuniziert (gleiches Protokoll, andere physikalische Ebenen). Enthält einen Überblick über Modbus RTU/ASCII und industrielle/CNC/Embedded-Einsätze (Debugging, Firmware, Reverse Engineering).
• Kapitel 4: warum es sich oft lohnt, SerialTools COM Sniffer zu verwenden: ein Serial-Port-Monitor auf Basis eines Windows-Kernel-Treibers, der Daten, IOCTL, Signale und Parameter bereits von anderer Software geöffneter Ports abfängt. Keine Kabel, präzise Filter, Export nach pcap/pcapng (z. B. für Wireshark) und stabil für lange Aufzeichnungen.

Wenn du schnell eine Drittanbieter-Software analysieren oder deine Anwendung kontinuierlich überwachen möchtest, beginne mit Kapitel 4 – COM Sniffer: der schnellste Weg zum Überwachen, Sniffen, Debuggen und Protokollieren – ohne Prüfstand.

Kapitel 1 – Daten vom COM-Port überwachen

1.1 Was „einen seriellen Port überwachen“ bedeutet

Einen COM- (seriellen) Port zu überwachen heißt, in Echtzeit die Bytes zu beobachten, die über die Kommunikationsleitungen zwischen PC und Gerät laufen. Üblicherweise unterscheidet man zwei Richtungen: TX (Übertragung vom PC zum Gerät) und RX (Empfang vom Gerät zum PC). Ein guter Monitor zeigt Daten sowohl als Text (ASCII/UTF-8-Interpretation) als auch in Hexadezimal (HEX), also die Rohbytes.

1.2 Bytes und Bits: logische Darstellung vs. serielle Übertragung

Beim Text Hello werden fünf Zeichen in fünf ASCII-Bytes umgesetzt: 48 65 6C 6C 6F in Hex. Ein Byte-Visualizer wie der von SerialTool zeigt die logische Wellenform der einzelnen Bits innerhalb jedes Bytes.

Bytes in der logischen Ansicht lesen

• Das Diagramm zeigt 8 Datenbits pro Byte (b7…b0). Im Speicher listet man sie oft als MSB→LSB (vom höchst zum niedrigst signifkanten Bit).
• Diese Darstellung enthält noch nicht die Elemente des seriellen Protokolls (Start, Parität, Stopp) und spiegelt nicht die Reihenfolge „auf der Leitung“ wider.

Wie Bytes über die serielle Schnittstelle übertragen werden

Auf der physischen RS-232/TTL-Leitung wird jedes Byte nach dem seriellen Rahmen gesendet:

Start (1 Bit, Logik „0“) → Daten (7/8 Bits, LSB zuerst) → Parität (optional) → Stopp (1 oder mehr Bits, Logik „1“).

• Leerlauf: Die TX-Leitung liegt stabil auf Logik „1“ (Mark). Sie bleibt auf 1, bis das Startbit kommt.
• Startbit: Ein Übergang zu „0“ (Space) signalisiert den Beginn des Bytes.
• Datenbits: werden in LSB-zuerst-Reihenfolge übertragen (zuerst das niederwertigste Bit).
• Stoppbit: Rückkehr zu „1“ für ein oder mehrere Bits; stellt den Leerlauf wieder her.
• Baudrate: bestimmt die Dauer eines Bits (z. B. bei 9600 Baud ≈ 104,17 µs je Bit).

Hinweis zu RS-232 vs. TTL

• Auf TTL-Ebene (UART bei 3,3 V/5 V) ist „1“ = High und „0“ = Low.
• Bei RS-232 sind die Pegel invertiert (Logik „1“ ≈ negative Spannung, Logik „0“ ≈ positive), die Start/Daten/Stopp-Sequenz bleibt jedoch identisch.

Schnelles Beispiel: Zeit für die Übertragung von „Hello“

Mit 8N1 (1 Start, 8 Daten, 1 Stopp) belegt jedes Byte 10 Bits auf der Leitung. Bei 9600 Baud sind das ~960 Bytes/s. Für 5 Bytes („Hello“) braucht es ~5,21 ms.

Kapitel 2 – Serielle Kommunikation mit zwei USB-zu-Seriell-Adaptern überwachen/sniffen, debuggen und protokollieren

2.1 Ziel

Einen nicht-invasiven seriellen Monitor/Sniffer aufbauen, um die zwischen Gerät 1 und Gerät 2 ausgetauschten Bytes zu beobachten, zu debuggen und zu protokollieren, ohne ihre Kommunikation zu unterbrechen.

2.2 Elektrische Anschlüsse (passives Abgreifen)

• COM5 (USB-zu-Seriell #1): Verbinde den RX-Pin des Adapters mit dem TX von Gerät 1 (snifft die vom Gerät 1 gesendeten Daten).
• COM6 (USB-zu-Seriell #2): Verbinde den RX-Pin des Adapters mit dem TX von Gerät 2 (snifft die vom Gerät 2 gesendeten Daten).
• Gemeinsames GND: Verbinde die Masse beider USB-Seriell-Adapter mit der der beiden Geräte (gemeinsame Referenz der Logikpegel).
• TX der Adapter nicht anschließen: Wir bleiben in „Nur-Hören“-Hochimpedanz, um die Leitung nicht zu stören.
• Keine Versorgung der Geräte aus 5 V/3,3 V der Adapter (VCC wird beim Abgreifen nicht verwendet).

Pegel-Hinweis: Diese Methode gilt für UART/TTL (3,3/5 V) oder Busse mit kompatiblen Treibern. Für RS-232 (±12 V) keinen TTL-RX direkt anschließen: Es braucht einen RS-232↔USB-Wandler oder einen speziellen RS-232-Tap/Monitor. Sprich: Wenn du eine RS-232-Leitung loggen willst, nutze passende Hardware.

2.3 Baudrate finden und einstellen

Damit die Daten korrekt dekodiert werden, müssen Baudrate und Parameter denen der Geräte entsprechen (z. B. 9600/8N1). Falls unbekannt:

• Dokumentation von Gerät oder Protokoll prüfen.
• Häufige Baudraten ausprobieren (9600, 19200, 38400, 57600, 115200 ...).
• Mit Oszilloskop/Logikanalysator messen: Bitdauer ist Tbit=1/Baud (z. B. bei 9600 Baud ≈ 104,17 µs pro Bit).

2.4 Die beiden COM-Ports mit SerialTool öffnen

1. Adapter verbinden: Das System sieht zwei Ports (im Beispiel COM5 und COM6).
2. In SerialTool zwei Sitzungen öffnen:
   • Sitzung A → COM5, Baud/Parität/Stopp wie bei den Geräten setzen (z. B. 115200/8N1).
   • Sitzung B → COM6, gleiche Parameter wie Sitzung A.
3. Beide in den Monitor-Modus (nur RX) versetzen: Auf COM5 siehst du die von Gerät 1 gesendeten Bytes, auf COM6 die von Gerät 2.
4. Fürs Debuggen die HEX-Ansicht und Zeitstempel nutzen; fürs Logging in Datei speichern (CSV/pcap/Raw) zur späteren Analyse.

In diesem Szenario agierst du als passiver physischer Man-in-the-Middle: Du überwachst/sniffst elektrisch, ohne die Signale zu verändern.

2.5 In diesem Beispiel ausgeschlossene Steuerpins

Das Diagramm fokussiert auf TX/RX-Daten und überwacht keine Steuerpins (z. B. RTS/CTS, DTR/DSR, DCD, RI). Für viele Anwendungen sind sie nicht nötig; nutzen die Geräte jedoch Hardware-Flow-Control, kann es sinnvoll sein, diese Leitungen mit speziellen Sonden „abzugreifen“.

Weiterführend: RS-232 (Wikipedia), RS-232 – Signale, Hardware-Flusskontrolle, UART.

2.6 Praxistipps für einen stabilen Monitor/Sniffer

• Kurze Kabel und sauberes gemeinsames GND verwenden; Masseschleifen vermeiden.
• Die meisten UART-Treiber tolerieren zwei RX-Eingänge (Fan-out) an einer TX-Leitung, unnötige Last aber vermeiden.
• Portparameter in beiden Sitzungen immer abgleichen (Baud, Daten, Parität, Stopp).
• Für RS-485 bzw. differentielle Busse spezielle Adapter und andere Abgreif-Regeln beachten.

Mit dieser Technik kannst du seriellen Verkehr zwischen zwei Geräten zuverlässig überwachen, sniffen, debuggen und protokollieren – mit gängigen Mitteln: zwei USB-zu-Seriell-Adapter + SerialTool.

Kapitel 3 – Sniffen/Überwachen der seriellen Verbindung zwischen „Master-PC“ und „Zielgerät“

3.1 Zweck und Konzepte

Wir wollen die zwischen Software auf dem Master-PC und dem Zielgerät ausgetauschten Bytes überwachen und sniffen, ohne die Kommunikation zu beeinträchtigen. Das ist ein typischer passiver physischer Man-in-the-Middle: zwei USB-zu-Seriell-Adapter, nur auf RX verbunden, „lesen“ jeweils eine Richtung. Nützlich für Debugging, Protokollanalyse und als Logger für Audits oder Reverse Engineering.

3.2 Anschlüsse (Schritt für Schritt)

1. COM5 (Sniffing-PC) → RX des Adapters an TX des Geräts (lauscht, was das Ziel sendet).
2. COM6 (Sniffing-PC) → RX des Adapters an TX des PCs (lauscht den Befehlen des Master-PC).
3. Gemeinsames GND zwischen beiden Adaptern und beiden Geräten (geteilte Referenz).
4. TX der Sniffing-PC-Adapter nicht verbinden: rein Listen-only (hohe Impedanz), ohne die Leitung zu stören.

In SerialTool zwei Sitzungen öffnen: COM5 und COM6. In beiden die Baudrate und das Format identisch zu Master/Ziel setzen (z. B. 115200-8N1). Unbekannte Baud? Häufige Werte testen oder Bitdauer mit Oszilloskop/Logikanalysator messen.

3.3 Gleiches Protokoll, unterschiedliche Ebenen: UART/TTL, RS-232, RS-485

Das asynchrone serielle Protokoll (Start, 7/8 Datenbits LSB-first, optionale Parität, 1+ Stopp) ist gleich. Es ändert sich nur die physikalische Ebene, auf der die Bits laufen:

• UART/TTL (3,3 V/5 V): single-ended, „1“ High / „0“ Low.
• RS-232: invertierte, ±-Spannungspegel (typisch ±3…±12 V), ebenfalls single-ended.
• RS-485: differentiell auf A/B-Paar, oft halbduplex Multi-Drop; gemeinsame Bezugsmassen empfohlen.

Daher den passenden Adapter nutzen: USB↔TTL für UART, USB↔RS-232 für RS-232, USB↔RS-485 für RS-485. Der Rahmen bleibt gleich, Pegel und Topologie (Differential/Terminierung) unterscheiden sich.

3.4 Einsatzgebiete (CNC, Industrie, u. a.)

Dieses Setup ist gängig in CNC, Industrieanlagen, PLC/HMI, Robotik, Waagen, POS, Sensorik, Messtechnik, Gebäudeautomation – überall, wo ein PC/PLC ein Gerät seriell steuert. Mit der beschriebenen Sniffing-Methode kannst du Verkehr überwachen/sniffen/debuggen/loggen zur Funktionsanalyse, Fehlerdiagnose, Befehlstracking und Validierung.

3.5 Modbus über seriell

Serielle Ports transportieren häufig Modbus RTU/ASCII, ein weit verbreitetes Master/Slave- (heute Client/Server-)Protokoll in der Industrie. Der Master sendet Anfragen (Lesen/Schreiben von Coils und Registern), das Gerät antwortet. SerialTool enthält einen Modbus-Client zum schnellen Abfragen von Registern (Diagnose/Tests) sowie Monitor/HEX-Ansicht für Rohrahmen (Adresse, Funktion, Daten, CRC).

3.6 Firmware-Update und Parametrierung

In der Embedded-Welt wird seriell oft für Firmware-Updates oder Parameterübergabe ans Ziel verwendet. Beispiele: Bootloader auf Custom-Boards, Arduino-Ökosysteme, diverse Mikrocontroller. Entwickler haben hier oft zwei Bedürfnisse:

1. Debuggen der Anwendung, die mit dem Ziel spricht (Befehle, Timing, Fehler prüfen).
2. Reverse Engineering eines bestehenden Protokolls (ein „geschlossenes“ Master-Programm spricht mit einem Board; ich sniffe die Nachrichten, um sie zu verstehen und später mit eigener Software zu replizieren).

3.7 Praxishinweise und Tools

• Typisch braucht dieses Setup zwei PCs (Master und Sniffing-PC) und mindestens zwei USB-zu-Seriell-Wandler fürs bidirektionale Sniffen.
• Für RS-232 einen RS-232-Tap/Converter nutzen; für RS-485 eine Empfangs-only-Schnittstelle an die A/B-Klemmen anschließen (Terminierung/Polarität beachten). Bei halbduplex RS-485 erkennt man die Richtung über den zeitlichen Kontext.
• Steuerpins (RTS/CTS, DTR/DSR, DCD, RI) bleiben außen vor; bei Hardware-Flow-Control ggf. dedizierte Sonden erwägen.
• In SerialTool kannst du HEX-Ansichten und Zeitstempel aktivieren und als Logger (Text/CSV/pcap) für spätere Analysen speichern.

Kurz: gleiches serielles Protokoll (asynchrone Rahmen), andere physikalische Ebenen (TTL/RS-232/RS-485). Mit passivem Zwei-RX-Abgriff und Software wie SerialTool kannst du die Kommunikation zwischen Master-PC und Zielgerät zuverlässig überwachen, sniffen, debuggen und protokollieren.

Kapitel 4 – COM Sniffer: Monitor/Sniffer/Debugger/Logger ohne physische Verkabelung

4.1 Was COM Sniffer macht

COM Sniffer ist ein Serial-Port-Monitor, der die Kommunikation auf einer COM-Schnittstelle abfängt, die bereits von einem anderen Programm geöffnet wurde. So kannst du den gesamten Verkehr (TX/RX) überwachen, sniffen, debuggen und protokollieren – ohne Kabel anzufassen, ohne Zusatzhardware und ohne den Betrieb von Master-PC oder Zielgerät zu beeinflussen.

4.2 Wie es funktioniert: Kernel-Treiber

Kernstück ist ein Kernel-Treiber für Windows, der sich in den Stack der seriellen Schnittstelle einklinkt und selektiv beobachtet:

• Datenpuffer beim Lesen/Schreiben (TX ↔ RX) mit klarer Trennung der Richtung;
• IOCTL (Input/Output Control): Öffnen/Schließen, Einstellungen für Baud/Parität/Stopp, Timeouts, Steuersignale (RTS/DTR/CTS/DSR/DCD/RI) usw.;
• Ereignisse/Signale und Portstatus (Line-Status, Modem-Status).

Der Treiber ist leistungsfähig, die Oberfläche bleibt einfach: Du kannst nach Typ filtern (nur Daten, nur Konfig-IOCTL, nur Signale etc.), um dich auf das Wesentliche zu konzentrieren. Ausgelegt für Langzeit-Aufzeichnungen (Stunden/Tage) – stabil, um deine App oder Drittsoftware zu überwachen. Hinweis: funktioniert nur unter Windows, da er auf Kernel-Mode-Treibern basiert.

4.3 Warum das in vielen Fällen besser ist als Verkabelung

• Kein „Labor“ aus zwei PCs + zwei USB-zu-Seriell: Zeit sparen und Fehlerquellen reduzieren.
• Null elektrischer Einfluss: Leitungen werden nicht belastet, keine Masseschleifen.
• Alles zwischen App und Treiber sehen: Daten, IOCTL, Signale – auch auf mehreren Ports parallel.

4.4 Logging und Export für Protokollanalyse

Du kannst direkt in eine Datei als Logger (Text/CSV) speichern oder nach pcap/pcapng exportieren – zur Analyse in Wireshark. Besonders hilfreich bei Industrieprotokollen wie Modbus RTU/ASCII: Mit Rahmen und Zeitstempeln prüfst du Timing, CRC, Funktionsfolgen usw.

4.5 Was sich beobachten lässt

• TX/RX-Daten getrennt, in ASCII und HEX mit Zeitstempeln;
• Portparameter, die die Software setzt (Baud, 7/8 Bits, Parität, Stopp, Timeouts);
• Steuersignale und IOCTL (RTS, DTR, CTS, DSR, DCD, RI) sowie Statusänderungen;
• Open/Close-Ereignisse und Fehler (Overrun, Framing, Parität).

4.6 Wann einsetzen

• Debugging deiner seriellen Anwendung ohne Code/Verkabelung zu ändern;
• Langzeitüberwachung von Drittsoftware für Audit/Diagnose;
• Reverse Engineering proprietärer Protokolle (wo rechtlich zulässig), um Funktionen mit eigener Software zu replizieren;
• Validierung von Standardprotokollen (z. B. Modbus) und Handshaking-Signalen.

4.7 Hinweise und weiterführende Links

COM Sniffer arbeitet auf Systemebene gemäß der Logik des asynchronen seriellen Protokolls (Start/Daten/Parität/Stopp). Nutzt die Anwendung andere physikalische Ebenen (UART/TTL, RS-232, RS-485), bleibt die Erfassung identisch, da sie oberhalb der elektrischen Ebene im Windows-COM-Port-Stack erfolgt.

Nützliche Links: Serial port · UART · RS-232 · RS-485 · IOCTL · Windows-Kernel-Treiber · Wireshark · Modbus.

Kurz gesagt: SerialTools COM Sniffer ist eine „reine Software“-Lösung zum Überwachen, Sniffen, Debuggen und Protokollieren einer von anderen Programmen geöffneten seriellen Schnittstelle – mit zuverlässigem Kernel-Treiber, gezielten Filtern und Export für tiefgehende Analysen.