| |
DG3DBI > TNC 30.05.94 00:36l 130 Lines 7979 Bytes #999 (0) @ DL
BID : 29541BDB0IZ
Read: GUEST DF6DBF DL1GHN DL7UAZ DL6PM
Subj: TNC4 Firmware + Gateway
Path: DB0KCP<OE9XPI<DB0CZ<DB0GE<DB0LJ<DK0MWX<DB0IZ
Sent: 940529/2206z @DB0IZ.#NRW.DEU.EU [Solingen, JO31NE, Op: DL6EE]
de DG3DBI @ DB0IZ.#NRW.DEU.EU
to TNC @ DL
Hallo TNC4/FALCon User !
Die neue Firmware Version 1.50 ist fertiggestellt.
Sie ermöglicht das lang erwartete Hopp-to-Hopp Digipeating bei via
Connects. Eine derartige Digipeaterfunktion war bisher reiner Digi-
peatersoftware wie Digiware oder Flexnet vorbehalten.
Diese Repeaterfunktion, die auch über verschiedene Ports abgewickelt
werden kann, ermöglicht zuverlässigen Gatewaybetrieb auch ohne Terminal-
programm und TNC-Überlauf. Für diejenigen, denen der Begriff Level 2
Hopp-to Hopp Digipeating noch nichts sagt, möchte ich hier noch kurz
eine Erläuterung der Funktionsweise geben:
Möchte ein Benutzer eine Verbindung mit einem anderen Benutzer oder einem
Netzeinstieg aufbauen und kann dieses aus verschiedensten Gründen nicht
direkt, wird oft der Gebrauch von sogennanten User-Gateways gemacht.
Im Regelfall besteht dieses Gateway aus einem weiteren Benutzer, der beide
Stationen hören kann und die Informationen wechselseitig weiterreicht. Dies
ist sowohl auf der selben Frequenz als auch sogar über verschiedene Bänder
möglich.
Diejenigen Benutzer, die anderen Ihre Station als sogenanntes Gateway zur
Verfügung stellen nutzen dabei meistens das in die Benutzerfirmware des TNCs
eingebaute Level 2 Digipeating oder mehrerer TNCs/Multiport-TNCs mit spe-
zieller Terminalsoftware. Beide Verfahren weisen jedoch einige Nachteile auf,
die hier kurz erörtert werden sollen.
Im einfachsten Fall verfügt der verwendete TNC über ein simples Level 2 Digi-
peating. Das heisst alle Aussendungen, die von einer Seite eingehen, werden
in direkter Form auf der gegenüberliegenden Seite wieder ausgegeben. Dies gilt
sowohl für Frames mit Informationen als auch Kontrollframes. Leider ist dieses
Verfahren besonders bei der Übertragung auf zwei unterschiedlichen Frequenzen
besonders störanfällig und uneffektiv. Ein an das Gateway ausgesandte Frame
wird empfangen und zunächst intern zwischengespeichert, aber gegenüber dem
Sender nicht bestätigt. Das Gateway sendet das so empfangene Frame auf der
zweiten QRG wieder aus, sobald diese frei ist. Der endgültige Empfänger be-
stätigt den Empfang, wobei diese Bestätigung erst wieder einmal das Gateway
passieren muß. Ist eine der Frequenzen zum Beispiel stark belegt und es kommt
hierdurch zu häufigen Kollisionen und somit Retrys wird die Situation nahezu
aussichtslos. Der Absender des Frames sieht erst einmal nur seine leere QRG
und gibt dieses an das Gateway weiter. Leider kann er den korrekten Empfang
seiner Aussendung beim Gateway nicht prüfen. Zusätzlich ist ihm unbekannt wie
lange das Gateway eventuell warten muß, um das Frame weiterzureichen und ob
der endgültige Empfänger die Aussendung des Gateways auch mitbekommen hat.
Dies wir erst durch die Bestätigung des endgültigen Empfängers wieder über
das Gateway klar. Da die Laufzeit über das Gateway aber zu jedem Zeitpunkt
unbekant ist und in starkem maße schwanken kann, muß die Zeit nach der eine
Aussendung wiederholt wird sehr hoch angesetzt werden. Anderenfalls wird die
Frequenz durch eine unnötig hohe Anzahl an Aussendungen belastet und weitere
Benutzer somit behindert. Eine Nutzung dieses Verfahrens ist somit besten-
falls auf einer einzigen und sehr leeren Frequenz sinnvoll anwendbar.
Ein zweites gängiges Verfahren für Benutzer Gateways ist die Verwendung
mehrerer TNCs oder eines Multiport TNCs sowie spezieller Terminalsoftware
die auf einem gesonderten Rechner wie z.B. IBM-PC oder Atari läuft. Hier wird
dem Absender seine Aussendung sofort vom entsprechenden TNC bestätigt. Dann
werden die reinen zu übertragenden Informationen an den gesonderten Rechner
übermittelt und von diesem wieder an den entsprechenden TNC für den zweiten
Teilnehmer gesendet, der das QSO wiederum selbstständig führt. Die Nachteile
des ersten genannten Verfahrens sind somit weitgehende aufgehoben.
Jedoch auch hier gibt es relevante Nachteile. Zum einem muß der Rechner mit
der Terminalsoftware ständig eingeschaltet bleiben und kann je nach Betriebs-
system während der Verbindung auch nicht anderweitig genutzt werden.
Zusätzlich tritt insbesondere bei großen Baudratenunterschieden auf den beiden
QRGs ein besonderes Problem auf. Bedingt duch den in der Regel verwendeten
WA8DED Hostmode für die Anbindung des Rechners an den/die TNCs ist eine ver-
nünftige Kontrolle des Datenflusses nicht möglich. Liest beispielsweise der
Benutzer auf der einen Seite auf einem stark belegten 1200 Baud Kanal über
ein solches Gateway eine Mailbox mit 9600 Baud Einstieg aus, so liefert die
Mailbox kontinuierlich Daten, die auch der 1200 Baud Seite nicht schnell
genug abgenommen werden können. Passiert dieses über eine längere Zeitspanne
ist auch der 1200 Baud TNC sowie der verwendete Rechner nicht mehr in der
Lage die gelieferten Daten zwischenzuspeichern. Der TNC "läuft über" und wird
normalerweise komplett zurückgesetzt. Dabei stürzt das Terminalprogramm in der
Regel ab und die Verbindung geht verloren.
Beim Level 2 Hopp-to-Hopp Digipeating wie es die Flexnet- und Digiware-Digi-
peater benutzen treten diese Probleme nicht auf. Das Verfahren entspricht im
Prinzip zwei voneinander getrennten TNCs die direkt ohne zusätzlichen Rechner
miteinander verbunden worden sind. Zusätzlich weiß jeder der beiden Ports über
die von anderen Seite gelieferte Datenmenge Bescheid. Wird von einer Seite
her ein einstellbares Limit an Puffern erreicht und die Informationen können
nicht sofort an den anderen Partner weitergegeben werden, schaltet diese Seite
in den "Busy" Zustand und teilt dem Sender mit, daß vorläufig keine Daten mehr
gesendet werden sollen (RNR-Zustand). Eine sogennante Hysterese sorgt dafür,
daß dem Sender die Erlaubnis zur Ausgabe weiterer Informationen erst dann
wieder genehmigt wird, wenn eine bestimmte Anzahl Puffer wieder dem Empfänger
zugestellt werden konnte (Window). Das gesamte Verfahren läuft selbstätig im
TNC ohne jegliches Zutun eines externen Rechners ab. Ein Verbindungsaufbau
zwischen den Benutzern A und B über das Gateway C wird dabei ohne Zwischen-
connect vom Benutzer A durch einen Connectbefehl "Connect B via C" ausgelöst.
Eine Bestätigung auf den Connectbefehl wird dem Benutzer A erst zugestellt,
nachdem C eine Meldung von B erhalten hat. Ab diesem Punkt laufen die beiden
QSOs praktisch unabhängig voneinander ab, bis die Verbindung aufgelöst wird.
Für die FALCon User sei hier nochmal kurz die Info gegeben, welche Ein-
stellungen für die Freigabe der Gatewayfunktion vorzunehmen sind:
Nachdem die Software entweder per Upload ins RAM geladen oder ins EPROM pro-
grammiert wurde, ist zuerst das @chans Kommando in Abweichung vom Handbuch wie
folgt erweitert worden:
Das Kommando @chans sollte mit 5 nummerischen Parametern versehen werden.
Die Parameter 1..4 geben wie im Handbuch beschrieben die Anzahl möglicher QSOs
pro Port an. Der fünfte Parameter spezifiziert die Anzahl möglicher Level 2
Hopp-to-Hopp QSOs. Alle fünf Parameter dürfen zusammen den Wert 100 nicht
überschreiten, wobei der fünfte Parameter doppelt zu zählen ist. Werden
weniger als 5 Parameter angegeben, so werden die fehlenden als 0 angenommen.
Nach der Ausführung des Kommandos sollte die Einstellung zuerst mit @update p
ins EEPROM übernommen werden und der TNC danach durch Ein- und Auschalten oder
das QRES Kommando zurückgestzt werden, da die Änderungen erst nach einem Reset
wirksam werden.
Für die Einstellung beim R-Kommando wird auf das Handbuch bzw. die Doku ver-
wiesen.
Mit dem bereits in der Vorgängerversion vorhandenen @window Kommando kann
gemäß dem Handbuch die Anzahl Puffer festgelegt werden, bei der ein QSO busy
wird und wann es wieder weitergeht.
Sollten noch Fragen offen sein, stehe ich für Auskünfte via Mailbox zur Ver-
fügung. Da es sich zwar um eine getestete Version handelt, aber Fehler wohl
nie auszuschließen sind, wäre ich über Erfahrungsberichte und ggf. Fehler-
beschreibungen erfreut.
Viel Spass mit dem TNC4 und der neuen Firmware.
73 de Werner DG3DBI @ DB0IZ
Read previous mail | Read next mail
| |
