Handbuch PTC-IIpro

10. Hostmode
158
1. Es besteht keine brauchbare Möglichkeit für eine Resynchronisation des Hostmode-
Ablaufs, falls das Protokoll aus irgend einem Grund durcheinander gerät. (Falls die
Neusynchronisation gelingt, führt dies trotzdem mit sehr hoher Wahrscheinlichkeit zu
fehlerhafter Datenübermittlung während der Synchronisationsphase.)
Im schlimmsten Falle genügt bereits ein einzelnes zerstörtes Bit im Datenstrom zwischen
PC und TNC, um einen Abbruch des Hostmode-Ablaufes zu bewirken.
2. Fehlerhafte Daten können nicht eindeutig erkannt werden und inbesondere können zerstörte
Daten nicht nochmals angefordert werden. Die Verbindung zwischen TNC und
PC erweist sich somit als Schwachstelle bei der fehlersicheren Übermittlung von Daten.
Eine integere Datenübermittlung vor allem sensibler Daten (Programme in 7PLUS oder
direkt binär) kann via ungesichertem WA8DED-Hostmodus aus diesem Grunde nur
eingeschränkt gewährleistet werden.
Übertragung via mehrere Knotenpunkte (z. B. WINLINK-Forwarding) erhöht das Fehlerpotential
durch Datenkorruption auf der RS232-Seite.
Hauptfehlerquellen in der Praxis:
• Bei aktivem Sendebetrieb kann HF zur Datenverstümmelung führen.
• Kurze Spikes durch heftige Ein-/Ausschaltvorgänge im Wechselspannungsnetz oder
auch Blitze in geringer Entfernung etc. erzeugen vor allem bei längeren RS232-Leitungen
Fehlerbursts.
• Langsame bzw. falsch konfigurierte Multitasking-Systeme (WINDOWS) neigen dazu,
durch zeitliche Überläufe Schnittstellenprobleme zu provozieren. Hier werden z. B.
in Rechenleistungsspitzen einzelne Zeichen oder sogar ganze Textstücke einfach verschluckt.
Der CRC-Hostmode löst diese beiden Probleme, indem jedes Hostmode-Datenpaket mit
einer hochsicheren CRC-Prüfsequenz ergänzt wird, somit also Fehler sehr gut erkannt werden
können. Zudem ermöglicht das CRC-Hostmode-Protokoll die Neuanforderung bzw.
automatische Neusendung als fehlerhaft erkannter Datenpakete.
10.8.1 Grundprinzipien
Die Ausdrücke Sende- bzw. Empfangspaket haben nichts mit tatsächlicher Aussendung bzw.
tatsächlichem Empfang auf der HF-Strecke zu tun; sie beziehen sich nur auf die RS232-
Schnittstelle. Das # Zeichen bedeutet Binärbyte.
Das Protokoll basiert auf dem extended Hostmode. Sämtliche Datenpakete werden nach den
Regeln dieses Unterprotokolles aufgebaut.
Der HOST (PC) ist wie beim WA8DED-Mode der MASTER, d.h. jede Aktion geht vom
PC aus; der TNC/PTC (=SLAVE) darf keinesfalls unaufgefordert senden.
Auf jede Aktion des MASTER muß genau eine Reaktion des SLAVE folgen. Der Master
muß diese Reaktion abwarten, bevor er eine neue Aktion startet. Es gibt allerdings ein
Timeout für diese Wartezeit (siehe unten).
Jedes WA8DED-Datenpaket wird durch einen (eindeutigen) Header bestehend aus #170-
#170 erweitert.
Jedes WA8DED-Datenpaket wird durch zwei CRC-Datenbyte (binär) am Ende ergänzt.
Der CRC berechnet sich genau nach den Vorgaben des CCITT-CRC16, entspricht also in
allen Einzelheiten dem bei PR und PACTOR eingesetzten CRC. Der CRC wird ab dem
ersten Byte nach dem #170#170-Header (=Kanalnummer) berechnet (CRC siehe AX.25-
Protokoll und Beispiel in Abschnitt 10.8.7 auf Seite 161).