Monitoren, sniffen, debuggen en loggen van de seriële poort

Op deze pagina ontdek je drie manieren om seriële communicatie tussen apparaten (pc, controllers, embedded boards) te analyseren en waarom SerialTool COM Sniffer vaak de beste oplossing is: volledig softwarematig, geen bekabeling, transparant, en geschikt als monitor/sniffer/debug/logger, zelfs voor dagenlange sessies.

Wat je zult vinden

• Hoofdstuk 1: wat het betekent om een COM-poort te monitoren, hoe bytes/bits zijn opgebouwd en hoe de seriële poort ze verzendt (start/data/pariteit/stop), plus TX/RX en baudrate.
• Hoofdstuk 2: de klassieke methode van fysiek sniffen met twee USB↔serieel-adapters: verbind alleen de RX met de TX-lijnen van de twee apparaten en deel de massa. Perfect als eenvoudige monitor/logger.
• Hoofdstuk 3: hetzelfde concept toegepast op een Master-pc die met een Doelapparaat praat via USB↔serieel/RS-232/RS-485-converters (zelfde protocol, verschillende fysieke niveaus). Inclusief een overzicht van Modbus RTU/ASCII en industriële/CNC/embedded use-cases (debug, firmware, reverse-engineering).
• Hoofdstuk 4: waarom het vaak loont om SerialTool COM Sniffer te gebruiken: een seriële poortmonitor gebaseerd op een Windows kernel-driver die data, IOCTL, signalen en parameters onderschept van poorten die al door andere software zijn geopend. Geen kabels, nauwkeurige filters, export naar pcap/pcapng (bijvoorbeeld voor Wireshark) en stabiel voor lange captures.

Als je doel is om snel een third-party programma te analyseren of je eigen applicatie continu te monitoren, begin dan bij Hoofdstuk 4 – COM Sniffer: dit is de snelste manier om te monitoren, sniffen, debuggen en loggen zonder een testopstelling te bouwen.

Hoofdstuk 1 – Data monitoren van de COM-poort

1.1 Wat betekent “een seriële poort monitoren”?

Het monitoren van een COM- (seriële) poort betekent in real-time de bytes observeren die over de communicatie­lijnen tussen pc en apparaat lopen. Bij monitoring onderscheiden we doorgaans twee richtingen: TX (transmissie van pc naar apparaat) en RX (ontvangst van apparaat naar pc). Een goede monitor toont data zowel als tekst (ASCII/UTF-8-interpretatie) als in hexadecimale vorm (HEX), dus de ruwe bytes.

1.2 Bytes en bits: logische representatie vs. seriële transmissie

Wanneer we de tekst Hello schrijven, worden de vijf karakters omgezet in vijf ASCII-bytes: 48 65 6C 6C 6F in hexadecimale vorm. Een byte-visualizer zoals die in SerialTool laat je de logische golfvorm van de afzonderlijke bits binnen elk byte zien.

Hoe bytes in de logische weergave te lezen

• De grafiek toont 8 data-bits per byte (b7…b0). In geheugen kunnen we ze in MSB→LSB volgorde tonen (most significant naar least significant bit).
• Deze representatie bevat nog niet de seriële protocol­elementen (start, pariteit, stop) en weerspiegelt niet de transmissie­volgorde op de lijn.

Hoe bytes over de seriële poort worden verzonden

Op de fysieke RS-232/TTL-lijn wordt elk byte ingekapseld volgens het seriële frame:

Start (1 bit, logische “0”) → Data (7/8 bits, LSB-first verzonden) → Pariteit (optioneel) → Stop (1 of meer bits, logische “1”).

• Idle: de TX-lijn staat stabiel op logische “1” (mark). Het signaal blijft 1 tot de startbit komt.
• Startbit: een overgang naar “0” (space) markeert het begin van het byte.
• Databits: databits worden in LSB-first volgorde verstuurd (least significant bit eerst).
• Stopbit: terug naar “1” voor 1 of meer bits; zorgt ervoor dat idle wordt hersteld.
• Baudrate: bepaalt de duur van elk bit (bijv. bij 9600 baud duurt elk bit ~104,17 µs).

Opmerking over RS-232 vs. TTL

• Op TTL-niveau (UART op 3,3 V/5 V) betekent “1” hoog en “0” laag.
• Op RS-232-niveau zijn de spannings­niveaus geïnverteerd (logische “1” ≈ negatieve spanning, logische “0” ≈ positieve), maar de volgorde start/data/stop blijft identiek.

Snel voorbeeld: tijd om “Hello” te verzenden

Met configuratie 8N1 (1 start, 8 data, 1 stop) gebruikt elk byte 10 bits op de lijn. Bij 9600 baud zijn dat ~960 bytes/s. Voor 5 bytes (“Hello”) is dat ongeveer 5,21 ms.

Hoofdstuk 2 – Seriële communicatie monitoren/sniffen, debuggen en loggen met twee USB-naar-serieel-adapters

2.1 Doel

Een niet-intrusieve seriële monitor/sniffer creëren om de bytes die tussen Apparaat 1 en Apparaat 2 worden uitgewisseld te observeren, te debuggen en te loggen, zonder hun communicatie te onderbreken.

2.2 Elektrische verbindingen (passieve tapping)

• COM5 (USB-naar-serieel #1): verbind de RX-pin van de adapter met de TX van Apparaat 1 (sniffen wat Apparaat 1 verstuurt).
• COM6 (USB-naar-serieel #2): verbind de RX-pin van de adapter met de TX van Apparaat 2 (sniffen wat Apparaat 2 verstuurt).
• Gemeenschappelijke GND: verbind de massa van beide USB-naar-serieel-adapters met die van de twee apparaten (gemeenschappelijke referentie voor de logische niveaus).
• Verbind de TX van de adapters niet met de bus: we blijven in “high-impedance” luistermodus, zodat we de lijn niet verstoren.
• Voed de apparaten niet vanuit de 5V/3,3V (VCC) van de adapters (VCC wordt bij tapping niet gebruikt).

Niveaunoot: deze methode geldt voor UART/TTL (3,3/5 V) of bussen met compatibele drivers. Voor RS-232 (±12 V) mag je een TTL-RX niet direct verbinden: je hebt een RS-232↔USB-converter of een speciale RS-232-tap/monitor nodig. Met andere woorden: als je een RS-232-lijn wilt loggen, gebruik de juiste hardware.

2.3 Baudrate vinden en instellen

Om data correct te decoderen moeten baudrate en parameters gelijk zijn aan die van de apparaten (bijv. 9600/8N1). Als je ze niet kent:

• Controleer de documentatie van apparaat of protocol.
• Probeer de meest gebruikte baudrates (9600, 19200, 38400, 57600, 115200...).
• Meet met een oscilloscoop/logic-analyzer: bitduur is Tbit=1/baud (bijv. bij 9600 baud ≈ 104,17 µs per bit).

2.4 De twee COM-poorten openen met SerialTool

1. Sluit de adapters aan: het systeem ziet twee poorten (in dit voorbeeld COM5 en COM6).
2. Open in SerialTool twee sessies:
   • Sessie A → COM5, stel baud/pariteit/stop in zoals de apparaten (bijv. 115200/8N1).
   • Sessie B → COM6, met dezelfde parameters als sessie A.
3. Zet beide in monitor (alleen RX): op COM5 zie je de bytes die Apparaat 1 verstuurt en op COM6 die van Apparaat 2.
4. Voor debugging gebruik je de HEX-weergave en timestamps; voor logging sla je naar bestand (CSV/pcap/raw) op voor latere analyse.

In dit scenario fungeer je als een passieve fysieke man-in-the-middle: je monitort/snifft data elektrisch zonder de signalen te veranderen.

2.5 Uitsluiting van control-pinnen in dit voorbeeld

Het schema concentreert zich op TX/RX-data en monitort geen control-pinnen (bijv. RTS/CTS, DTR/DSR, DCD, RI). Voor veel toepassingen zijn die niet nodig; als de apparaten echter hardware flow control gebruiken, kan het nuttig zijn die lijnen met speciale probes te “tappen”.

Verdere lectuur: RS-232 (Wikipedia), RS-232 – signalen, Hardware-flowcontrol, UART.

2.6 Praktische tips voor een stabiele monitor/sniffer

• Gebruik korte kabels en een goede gemeenschappelijke GND; vermijd aardlussen.
• De meeste UART-drivers verdragen twee RX-ingangen op één TX-lijn, maar vermijd onnodige belasting.
• Zorg dat de poort­parameters in beide sessies gelijk zijn (baud, data, pariteit, stop).
• Voor RS-485 of differentiële bussen heb je specifieke adapters en andere tapping-regels nodig.

Met deze techniek kun je betrouwbaar monitoren, sniffen, debuggen en loggen van seriële communicatie tussen twee apparaten met standaardmiddelen: twee USB-naar-serieel-adapters + SerialTool.

Hoofdstuk 3 – De seriële link tussen “Master-pc” en “Doelapparaat” sniffen/monitoren

3.1 Doel en concepten

We willen de bytes die tussen de software op de Master-pc en het Doelapparaat lopen monitoren en sniffen, zonder de communicatie te verstoren. Dit is een typisch voorbeeld van een passieve fysieke man-in-the-middle: twee USB-naar-serieel-adapters die alleen met RX in beide richtingen “meelezen”. Dit is nuttig voor debug, protocolanalyse en als logger voor auditing of reverse-engineering.

3.2 Verbindingen (stap voor stap)

1. COM5 (Sniffing-pc) → verbind de RX van de adapter met de TX van het Doelapparaat (luister naar wat het apparaat verstuurt).
2. COM6 (Sniffing-pc) → verbind de RX van de adapter met de TX van de pc (luister naar de commando’s van de Master-pc).
3. Gemeenschappelijke GND tussen de twee adapters en de twee apparaten (gedeelde referentie).
4. Verbind de TX van de adapters van de Sniffing-pc niet: we blijven in listen-only modus (hoge impedantie), zonder de lijn te storen.

Open in SerialTool twee sessies: COM5 en COM6. Stel in beide sessies de baudrate en het formaat in zoals gebruikt door Master/Device (bijv. 115200-8N1). Als de baudrate onbekend is, probeer dan gangbare waarden of meet de bitduur met een oscilloscoop/logic-analyzer.

3.3 Zelfde protocol, andere niveaus: UART/TTL, RS-232, RS-485

Het asynchrone seriële protocol (start, 7/8 databits LSB-first, optionele pariteit, 1+ stopbit) is hetzelfde. Alleen het fysieke niveau waarop de bits worden verzonden, verandert:

• UART/TTL (3,3 V/5 V): single-ended signalen, “1” is hoog / “0” is laag.
• RS-232: geïnverteerde en ± spannings­niveaus (typisch ±3…±12 V), eveneens single-ended.
• RS-485: differentiële signalering op A/B-paar, vaak half-duplex multi-drop; een gemeenschappelijke referentie-massa wordt aanbevolen.

Gebruik daarom de juiste adapter: USB↔TTL voor UART, USB↔RS-232 voor RS-232, USB↔RS-485 voor RS-485. Het frame blijft identiek, maar de elektrische niveaus en topologie (differentieel/terminatie) verschillen.

3.4 Waar wordt dit gebruikt (CNC, industrie, enz.)

Deze opstelling is gebruikelijk bij CNC, industriële machines, PLC/HMI, robotica, weegschalen, POS-systemen, sensoren, meetinstrumenten, gebouwautomatisering en in het algemeen in elk systeem waar een pc/PLC een apparaat via seriële communicatie aanstuurt. De hier beschreven sniffmethode laat je het verkeer monitoren/sniffen/debuggen/loggen voor functionele analyse, foutdiagnose, trace van commando’s en validatie.

3.5 Modbus via seriële poort

Seriële lijnen vervoeren vaak Modbus RTU/ASCII, een veelgebruikt master/slave- (nu client/server-) protocol in de industrie. De Master stuurt aanvragen (read/write van coils en registers) en het apparaat antwoordt. SerialTool bevat een Modbus-client om snel registers uit te lezen (diagnostiek en testen), naast de monitor/hex-viewer die nuttig is om ruwe frames te bekijken (adres, functie, data, CRC).

3.6 Firmware-update en parameterisatie

In de embedded wereld wordt seriële communicatie veel gebruikt voor firmware-updates of het doorgeven van parameters aan het Doelapparaat. Voorbeelden: bootloaders op custom boards, ecosystemen zoals Arduino, diverse microcontrollers. Een ontwikkelaar heeft hier vaak twee behoeften:

1. Debuggen van de applicatie die met het Doelapparaat praat (commando’s, timing, fouten controleren).
2. Reverse-engineering van een bestaand protocol (er is een “gesloten” Master-software die met een board praat; ik snif mee om de berichten te begrijpen en ze vervolgens met mijn eigen software te reproduceren).

3.7 Praktische opmerkingen en tools

• Deze opstelling vereist meestal twee pc’s (Master en Sniffing-pc) en minstens twee USB-naar-serieel-converters voor bidirectioneel sniffen.
• Voor RS-232 gebruik je een RS-232-tap/converter; voor RS-485 sluit je een receive-only interface aan op de A/B-klemmen (rekening houdend met terminatie en polariteit). Bij half-duplex RS-485 leid je de richting af uit de timing.
• Control-pinnen (RTS/CTS, DTR/DSR, DCD, RI) laten we hier buiten beschouwing; als het systeem hardware flow-control gebruikt, overweeg dan speciale probes.
• In SerialTool kun je HEX-weergave, timestamps en logging als logger (tekst/CSV/pcap) inschakelen voor latere analyse.

Kortom: hetzelfde seriële protocol (asynchrone frames), andere fysieke niveaus (TTL/RS-232/RS-485). Met passieve tapping via twee RX-lijnen en software zoals SerialTool kun je betrouwbaar monitoren, sniffen, debuggen en loggen van de communicatie tussen een Master-pc en een Doelapparaat.

Hoofdstuk 4 – COM Sniffer: monitor/sniffer/debug/logger zonder fysieke bekabeling

4.1 Wat COM Sniffer doet

COM Sniffer is een seriële poortmonitor die de communicatie op een COM-poort die al door een ander programma is geopend onderschept, zodat je het volledige verkeer (TX/RX) kunt monitoren, sniffen, debuggen en loggen zonder kabels aan te raken, zonder extra hardware en zonder de werking van de Master-pc of het Doelapparaat te beïnvloeden.

4.2 Hoe het werkt: kernel-driver

De kern is een kernel-driver voor Windows die zich in de seriële poortstack “tussenvoegt” en selectief het volgende observeert:

• Databuffers die worden gelezen/geschreven (TX ↔ RX) met een duidelijke scheiding per richting;
• IOCTL (Input/Output Control): openen/sluiten, instellingen voor baud/pariteit/stop, time-outs, control-signalen (RTS/DTR/CTS/DSR/DCD/RI), enz.;
• Events/signalen en poortstatus (line status, modem status).

De driver is krachtig, maar de interface blijft eenvoudig: je kunt filteren op type (alleen data, alleen configuratie-IOCTL, alleen signalen, enz.) om je te concentreren op wat belangrijk is. Hij is ontworpen voor langdurige captures (uren/dagen) en werkt stabiel om jouw applicatie of die van derden te monitoren. Let op: hij werkt alleen op Windows omdat hij afhankelijk is van kernel-mode drivers.

4.3 Waarom dit vaak beter is dan fysieke bekabeling

• Geen “lab” met twee pc’s + twee USB-naar-serieel-adapters: je bespaart tijd en vermindert foutbronnen.
• Geen elektrische invloed: je belast de lijn niet en vermijdt aardlussen.
• Je ziet alles tussen applicatie en driver: data, IOCTL, signalen, zelfs op meerdere poorten tegelijk.

4.4 Logging en export voor protocolanalyse

Je kunt direct naar bestand opslaan als logger (tekst/CSV) of exporteren naar pcap/pcapng voor analyse in Wireshark. Dit is bijzonder handig voor industriële protocollen zoals Modbus RTU/ASCII: met frames en timestamps kun je timing, CRC en functiesequenties valideren.

4.5 Wat je kunt observeren

• TX/RX-data afzonderlijk, in ASCII en HEX, met timestamps;
• Poort­parameters die door de software worden ingesteld (baud, 7/8 bits, pariteit, stop, time-outs);
• Control-signalen en IOCTL (RTS, DTR, CTS, DSR, DCD, RI) en hun status­veranderingen;
• Open/close-events en fouten (overrun, framing, pariteit).

4.6 Wanneer je het gebruikt

• Debug je seriële applicatie zonder code of bekabeling aan te passen;
• Langdurige monitoring van third-party applicaties voor audit/diagnose;
• Reverse-engineering van eigen protocollen (waar toegestaan) om functies met je eigen software na te bouwen;
• Validatie van standaardprotocollen (bijv. Modbus) en handshake-signalen.

4.7 Opmerkingen en verdere lectuur

COM Sniffer werkt op systeemsniveau volgens de logica van het asynchrone seriële protocol (start/data/pariteit/stop). Als de applicatie verschillende fysieke niveaus gebruikt (UART/TTL, RS-232, RS-485), blijft de capture identiek, omdat deze boven het elektrische niveau plaatsvindt, in de Windows-stack van de COM-poort.

Nuttige links: Serial port · UART · RS-232 · RS-485 · IOCTL · Windows kernel-drivers · Wireshark · Modbus.

Samengevat: SerialTool COM Sniffer is een “software-only” oplossing om een seriële poort die door andere programma’s is geopend te monitoren, sniffen, debuggen en loggen, met een betrouwbare kernel-driver, gerichte filters en export voor geavanceerde analyse.