Hinweis: Dieses Handbuch sowie seine Quelltexte dürfen nur zur nicht-kommerziellen Verwendung im Amateurfunk benutzt, kopiert oder sonstwie verwendet werden.

Das Einspielen dieser Dokumentation (ausser dem User-Teil) in Datennetzen ist ausdrücklich nicht gestattet.

Weitergabe des Handbuch sowie seine Quelltexte ist nur komplett und ohne Änderungen gestattet.

Für die Weitergabe darf kein Geld oder sonstige Gegenleistungen verlangt werden, ausser für die Kosten für das Medium und Porto. Ausdrücklich untersagt ist die Entschädigung für Arbeitsaufwand, -ausfall und dergl.

Alle Angaben ohne Gewähr für die Richtigkeit.

 

 

Überblick

Installation

Voraussetzungen

Parameter Compiler und Config-Datei

Einstellung der Port Parameter auf die verwendeten Modeme

Hostmode & TermWare

Allgemein

Übersicht über Sysop - Befehle

Generelles

Beispiele

AX.25 bezogene Parameter

SCC bezogene Parameter

V24 bezogene Parameter

KISS bezogene Parameter

Gesamtsystembezogene Parameter

Texte

Systemmanipulation

Flexnetrouter

Convers

Vernetztes Convers (ConversD)

Diagnose+Manipulation im laufenden Betrieb

Debug-Interface

User Sicht

Besonderheiten

User Befehle

Die Quelltexte

Lizenz, Rechtslage, Verwendung in eigenen Projekten

Generelles

Bedingte Kompilierung

Hardware Treiber

Inhalt Quellarchiv

Funktionsweisen

Probleme

Verwendete Resourcen des V25+

Sonstiges

Häufige Fehler

Anschluss von ...

Befehlsvergleich

Glossar

Autoren & Unterstützer

Adresse

LIZENZBESTIMMUNG

ConversD - Vernetztes Convers

Das Conversd Protokoll

SMACK = KISS + CRC

SMACK - Protokollbeschreibung

FLEX-CRC-KISS Verfahren (Ergänzung v. dg9ep)

Hinweise zum TNC4 (FALCon)

Anl. Upload mit der TNC4-FALCon-Firmware (nicht DigiWare oder TermWare)

RAM-Extension

Aufbau der TNC4 (FALCon)-RAM-Extension Platine

V24-Handshake

Warum ich KISS als HF-Schnittstelle nicht mag...

DigiWare macht vieles möglich, womit man sich als Sysop unter Umständen *SEHR* unbeliebt machen kann....

FlexNet-Router - Funktionsweise

Kurze Übersicht

Prinzipien

Das Routingprotokoll

Generelles zum Flexnet-Protokoll:

DCF-77-Kram

Literatur

Schaltungen

Index

 

Überblick

TermWare & HOSTMODE Beschreibung, siehe Seite *

 

DigiWare ist eine Software für den Einsatz bei PR-Digipeatern. Sie nutzt die zum Betrieb notwendige TNC4 (FALCon) Hardware optimal aus.

DigiWare entstand parallel zur Entwicklung des TNC4 (FALCon), daher konnten beide Projekte sehr gut aufeinander abgestimmt werden.

Durch die Flexibilität des DigiWare zugrunde liegenden Konzepts und da die Software im Quellformat verfügbar ist, sollte eine Portierung von DigiWare auf andere PC-gestützte Systeme relativ problemlos möglich sein.

 

DigiWare/TermWare wird unter den Bedingungen der Allgemeinen Lizenz für Amateurfunk Software (ALAS) jedem ernsthaft Interessierten zugänglich gemacht.

 

Übrigens: DigiWare/TermWare ist keine "Einstecken + fertig" (Plug'n play) Software, wie beispielsweise das RMNC/Flexnet-Konzept der Frankfurter PR-Gruppe. Umfang der DigiWare/TermWare-Befehle, Größe des Programms und Anzahl der Möglichkeiten liegen ja deutlich über dem, was bisher auf Einplatinenknotenrechnern gängig war. Mit den in jeder normalen Sysop-Gruppe von Funkamateuren vorhandenen Kenntnissen sollte aber trotzdem der Betrieb von DigiWare/TermWare problemlos möglich sein.

 

Achtung: Seit der Version 0.93 hat sich die Parametrisierung grundlegend geändert; dies ist hier noch nicht ausreichend dokumentiert!fhgfhf

Installation

Voraussetzungen

Für den Betrieb von DigiWare/TermWare ist ein TNC4 (FALCon) mit 256kB RAM und 256 kB EPROM notwendig. Zur individuellen Parametrisierung ist ein PC notwendig, da der Parametercompiler und der Passwortgenerator auf DOS angewiesen ist. Desweiteren natürlich einen EPROMmer, der 27c2001 brennen kann (U.U. kann man auch kleinere EPROMmer verwenden, indem man Adapter verwendet, und mehrfach brennt). Dieser EPROM-Typ ist notwendig, da DigiWare/TermWare im Gegensatz zur TNC4 (FALCon)-Firmware mehr als 128k EPROM Platz benötigt. Dabei muß man darauf achten, daß die entsprechenden Jumper richtig gesteckt sind (s.TNC4 (FALCon) Benutzerhandbuch oder im Anhang S.* ).

 

DigiWare/TermWare kann auch auf einem handelsüblichen PC (80286 ff., 500k freier RAM) ablaufen. Da damit aber zur Zeit nur KISS-TNCs ansteuerbar sind, rate ich DRINGEND davon ab, PC/DigiWare/TermWare (also auf dem PC) ernsthaft zu betreiben (egal ob als Digi oder zu Userzwecken). Als Entwicklungstool dagegen ist PC/DigiWare/TermWare hervorragend geeignet - deshalb ist er auch gebaut worden... (s. Seite * Quelltexte).

Übrigens: Der Aufruf der PC-Version muß mit dem CONFIG-Filenamen als Argument erfolgen (die Anwendung des Parameter Compilers ist beim PC überflüssig und auch gar nicht möglich). Beispiel:

FD DB0XY.cfg

ansonsten sucht DigiWare/TermWare automatisch nach DIGIWARE/TERMWARE.CFG. Ist diese Datei auch nicht da, gibt es einen Laufzeitfehler.

Parameter Compiler und Config-Datei

Die Datei, die die Software enthält muß vor dem Brennen in ein EPROM auf die individuellen Belange (das sind insbesondere Rufzeichen des Digis, und dessen Ausstattung mit Ports, Modeme und Links) eingestellt werden. Dies geschieht mit Hilfe des auf der Diskette befindlichen Parametercompilers PARACOMP.EXE unter DOS.

Dieser Compiler verbindet die individuellen Konfigurationen, die in einer mit jedem normalen ASCII Editor editierbarer Datei enthalten sind, mit dem ausführbaren Programm FD.EXE.

 

Dazu sind die folgenden Schritte notwendig.

1. Erzeugen der Datei FD.EXE. Dies geschieht entweder durch Kopieren dieser Datei von der gelieferten Diskette, oder das Erzeugen durch einen Compiler mit Hilfe der Quältest (s.u.).

2. Editieren einer CFG Datei (s.u.). Dieses ASCII Datei enthält alle nötigen Zeilen, die der Digipeater nach einem Kaltstart ausführen soll. Als Syntax ist genau dieselbe zu verwenden, die auch bei der normalen "Pflege" des Digis durch den Sysop per PR benutzt wird.
Achtung: Der Parameter-Compiler gibt bei falschen Zeilen (Schreibfehler etc.) nicht immer Fehlermeldungen aus! Man muß also sorgfältig bei der Zusammenstellung vorgehen.

3. Man ruft den Patchcompiler auf. Als Argument ist der Name des Exefiles und der Konfigurationsdatei anzugeben. Beispiel:

 

PARACOMP FD.EXE DB0ME.CFG

 

Daraufhin arbeitet der PC eine Weile.

4. Nachdem dem er fertig ist, wandelt man den EXE-File mittels FALCLDR.EXE in einen Binärfile um. Aufruf:

 

FALCLDR -w 0 -c 0 -bs 2048 -272001 FD.EXE FD.BIN

 

Dadurch wird FD.BIN erzeugt, dessen Inhalt dann in einen EPROM 27C2001 gebrannt werden kann. Die Baudrate der Debug-V24 (0) ist standardmässig bei 9600bd (-w 0 = 0 Waitstates; -c 0 Debug-Interface Ausgaben auf V24-0; -bs 2048 V24-Buffergrösse dafür 2 kByte; -272001 EPROMtyp). Bis auf die Waitstates sollte man die Einstellungen nicht ändern.

Es ist nicht möglich ein unbehandeltes EXE - File zu brennen / upzuloaden.

Ein einmal behandelter EXE-File kann beliebig oft neu mit dem Parameter Compiler behandelt werden. Allerdings darf die Größe des CFG-Files in keinem Falle 9k (ohne Kommentare) überschreiten.

Ein bereits umgewandeltes BIN-File DARF nicht mit dem Paracompiler behandelt werden!

Einstellung der Port Parameter auf die verwendeten Modeme

ModemG3RUH

ClkModus $66; SIMPLEX/DUPLEX; NRZI=1

ModemDF9IC

ClkModus $08; SIMPLEX/DUPLEX; NRZI=0

ext.Loopback
ModemTCM3105
ModemAM7911

ClkModus $76; SIMPLEXSPEZIAL; NRZI=1

 

evtl. falsche Baudrate, dann TCM3105, AM7911: ClkModus $7E; SIMPLEX/DUPLEX; NRZI=1; ext.Loopback geht dann NICHT (macht PTT-Hänger, Rx braucht Flanke zum Starten!)

Config-File Beispiel:

(für eine Beschreibung der Befehle schlage man an der entsprechenden Stelle weiter unten in diesem Dokument nach)

;

; CONFIG FILE FÜR DIGIWARE/TERMWARE

; Semikolon in der 1.Spalte kennzeichnet einen Kommentar

;

;Password-Befehl MUSS immer vorhanden sein

;(übrigens: 1 ist NICHT der Password-Startwert bei DB0ME :-) )

Password 1

; als nächstes starten wir mal die SCCs

P p1 sccstart 1

p p2 sccstart 2

p p3 sccstart 3

p p4 sccstart 4

; und den Loopback-Treiber, damit man an der v24 was davon hat

p p5 loopStart 1

; Rufzeichen für jeden der Ports setzen - Immer auch für PORT 1!

MYCALL 1 DB0ME

MYCALL 2 DB0IZ

MYCALL 3 DB0ME

MYCALL 4 DB0IZ

MYCALL 5 DB0ME

;Bei Sysop ist der SSID ist relevant!

PARAMETER SYSOP DG9EP-1

p MYQTH JO31LF

;

p p1 InterLink t1 75 t2 5 t3 90 RNRt 500 baud 384 clk 118 NRZI 1

p p1 retry 20 paclen 256 maxFr 5 map 3 txd 3 dwait 1 SIMPSPEZ

;

; An Port 2 ist über einen TNC2 (der nur über TxD/RxD mit dem

; TNC4 (FALCon) verbunden ist) eine Mailbox angeschlossen.

;

p p2 InterLink t1 150 t2 1 t3 170 RNRt 500 baud 19200 clk 118 NRZI 1

p p2 retry 20 paclen 256 maxFr 4 map 4 txd 1 dwait 1 txw 2048

p p2 rxw 2048 SIMPSPEZ l2digi off

;

;An Port 3 befindet sich ein G3RUH-Modem, das mit 19200 Baud betrieben wird:

;

p p3 User t1 150 t2 10 t3 170 Rnrt 500 baud 19200 clk 102 NRZI 1 SIMPLEX

p p3 retry 20 paclen 256 maxFr 7 map 3 txd 4 dwait 5 txw 2048 rxw 2048

;

;An Port 4 befindet sich auch ein G3RUH, aber mit 9600 Baud:

p p4 User t1 150 t2 10 t3 170 Rnrt 500 baud 9600 clk 102 NRZI 1 SIMPLEX

p p4 retry 20 paclen 256 maxFr 7 map 4 txd 4 dwait 10 txw 2048 rxw 2048

;

link add ziel

link add ziel DB0ME-11 port 1 HIDDEN NOMEASURE "TNC4 (FALCon) 1"

link add ziel DB0IZ-0 port 2 PUBLIC NOMEASURE "Box"

link add ziel DB0IZ-5 port 2 HIDDEN NOMEASURE "Box"

link add ziel DB0ME port 3 PUBLIC NOMEASURE "19200-Baud-Einstieg"

link add ziel DB0IZ-9 port 4 PUBLIC NOMEASURE "9600-Baud-Einstieg"

li ad zi SG96 port 4 HIDDEN NOMEASURE "9600-Baud-Einstieg"

 

link add ziel DB0BM via DB0ME-11 FlexNet PUB MEA "Juelich"

link add ziel DL0WST v DB0ME-11 FlexNet PUBLIC MEASURE "Birk/Bonn"

link add ziel DB0END via DB0ME-11 PUBLIC MEASURE "Ennepetal"

link add ziel DB0RWI v DB0ME-11 FlexNet PUBLIC MEASURE "Duesseldorf"

 

l a z DB0ONA v DB0ME-11 NETROM PUBLIC MEASURE "Idarkopf"

l a z DB0QS v DB0ME-11 TCPIP PUBLIC MEASURE "Dinslaken"

l a z DB0QS-7 v DB0ME-11 TCPIP HIDDEN NOMEAS

l a z DB0GOS v DB0QS-7 PUBLIC "Essen"

 

Beac add Port 3 Minuten 2 z FALCon "##INFO##"

Beac add Port 3 Minuten 10 z FALCon "##REMOTE##"

Beac add Port 3 Minuten 5 z FALCon "##LINK##"

Beac add Port 4 Minuten 2 z FALCon "##INFO##"

Beac add Port 4 Minuten 10 z FALCon "##REMOTE##"

Beac add Port 4 Minuten 5 z FALCon "##LINK##"

;

p CTEXT - DG9EP - Hochdahl - JO31LF

; Am Ende der Datei sollte immer der Prompt Befehl benutzt werden.

; Ansonsten gibt DigiWare/TermWare GAR KEINEN PROMPT aus.

PROMPT %c de %d%s (%t Local)->

; das END ist ebenfalls immer notwendig.

END

Hostmode & TermWare

Allgemein

Ist im Quelltext der Schalter $HOSTMODE eingeschaltet, so ist auf der ersten (oder war es die zweite?) V24 des FALCon der Hostmode installiert (initial mit 19200 Baud auf dem FALCon bzw. 9600 für die PC-Version).

Zeilen im CFG Files wie "p port 7 fiss 0" sollten auskommentiert werden

Unabhängig davon ist zur Zeit (20. August 1995) kein KISS/SMACK Mode mehr aktiviert.

 

Wird der FALCon von außen connected und ist das ZielCall (also das eigene) im Bereich 0 bis 4 (also z.B. DG9EP-3) , dann wird automatisch der Connect an das Hostmodeterminal weitergeleitet (sofern vorhanden und aktiv). Die Werte 1-4 sind z.Zt. hart kodiert.

 

Die Ausgabe im Monitor Fenster entspricht dem üblichen Ausgabeformat einer TF2.x.

 

Leider ist der Hostmode nicht sehr schnell (eff 7000 Baud bei 19k2 auf der v24; eff. 11500 Bd. bei 38k4).

 

Hostmode ist auch in der PC-Version lauffähig.

Befehle in der INFOBOX

HOST

In der Infobox. Baut eine Verbindung zum Hostmode-Terminal (z.B. PC mit GP) auf, sofern es da ist. Ist es nicht da, kommt entsprechende Meldung.

Die gleiche Meldung erhält ein von außen Connectender, wenn das Hostterminal busy oder nicht aktiv ist.

Befehle des Hostmode (Terminalprogrammseite)

Im Prinzip funktionieren alle relevanten Hostmode Befehle. Alle Kanalparameter (ESC P ESC W ESC T ...) müssen aber in DigiWare/TermWare eingestellt werden! Gibt man die Befehle in GP ein, so melden sie glaub ich keinen Fehler zurück, aber tun auch nix allzu sinnvolles

C FALCON

baut eine Verbindung mit der Infobox des FALCon auf - dort können und sollten alle DigiWare/Termware Parameter (Modem, Txdelay, MYCALL etc) eingeschaltet werden

 

C

Gibt man den Befehl C mit irgendeinen Call ein, so passiert das gleich als ob man dies im FALCon eingeben würde. Es wird also mittels MH-Liste und Linkliste der Port und der Weg ausgewählt.

 

M Monitor

funktioniert wie bei der TF man kann aber den Port auswählen: M 1234 schaltet den Monitor für Port 1-4 ein. Beispiel:

M IU 346 + DG9EP DL7GAI

 

@K

schaltet um in KISS mode - geht aber nicht

Übersicht über Sysop - Befehle

Generelles

Diese Befehle sind nur einem Sysop zugänglich. Dieser muß sich per PRIV Befehl als solcher autorisiert haben.

Die Notation der nachfolgenden Befehle erfolgt in der üblichen EBNF. Dabei sind [] optionale Parameter; {} sind wiederholbare Teile; und | steht zwischen alternativer Formen des Befehls.

Beispiel:

<AnAus> ::= ON | AN | OFF | AUS | 1 | 0

 

Anstelle von <AnAus> kann also ON oder 1 oder AUS geschrieben werden, aber nicht gleichzeitig.

 

Man muß bei DigiWare/TermWare unterscheiden zwischen den physikalischen Ports (also wirklich vorhandenen, an denen man was anlöten muß/kann) und logischen Ports auf die erstere (fast) beliebig verteilt werden können. Die logischen Ports werden von DigiWare/TermWare alle gleich behandelt, egal ob SMACK, SCC, Loopback oder KISS. Die notwendige Unterscheidung wird sozusagen tief drin in DigiWare/TermWare vorgenommen - das interessiert aber unseren AX25 - Protokollabarbeitungsteil der Soft nicht!

Damit nun DigiWare/TermWare genau weiss, welche physikalische Schnittstelle zu welchem logischen Port gehört, muß dies durch diverse Befehle mitgeteilt werden... $TODO

Aktuelles

hiermit wird der Text AKTUELLES ausgeben. Dieser Text ist für aktuelle Meldungen vorbehalten, z.B. geplante Änderungen in der nächsten Zeit, Hinweise auf neue Links usw. Der Text wird vom Sysop eingegebene werden.

Zur Eingabe des Aktuell Textes ist vom Sysop das Kommando

WRITE AKT

einzugeben. S. WRITE

BEACON [ADD|INS|DEL|CHANGE] [NR <wert>] [PORT <wert>] [MINUTEN <wert>] [ZIEL <Ziel> [VIA <pfad> ]] [text]

 

<Ziel> = Rufzeichen (z.B. BAKE)

<pfad> = Rufzeichenpfad (z.B. dg9ep dg3dbi dl1ebq)

 

Baken auflisten und einrichten. Neue und geänderte Baken werden direkt nach drei Minuten zum ersten mal ausgesendet (unabhängig von der eingestellten Zeit). Als besondere Bake gibt es ##INFO## (Rufzeichen und techn. Daten), ##LINK## (Linkzeiten), ##REMOTE## (Status upgeloadeter Programme).

 

Beispiel

BE ADD PORT 4 MIN 5 ZIEL FALCon "DB0ME mit TNC4 (FALCon)/DigiWare"

 

Im TEXT können auch Makros verwendet werden:

 

B A P 4 MIN 5 Z FALCon "%d mit TNC4 (FALCon)/DigiWare%num%l"

 

ergibt als BakenText bei der Aussendung z.B.

 

DB0ME mit TNC4 (FALCon)/DigiWare

um 17:49

FIND <Call>

(Kein Sysop-Befehl, aber noch nicht fehlerfrei)

Sucht Call. Wenn Call mit/oder über dem Digi arbeitet, wird

*** <call> is using this Digi

ausgegeben (dann USER LONG verwenden um den Weg rauszufinden bzw. einfach connecten ohne Angabe des Pfades, da der MH-Router den Weg dann kennt). Ansonsten wird über alle Digis die in der Link Liste stehen, ein UI mit Poll gesendet (das Adressfeld ist dabei in Ordnung und nicht verdreht). Kommt das entsprechende DM vom gesuchten Call, bekommt der Aufrufer die Meldung "found via DB0xyz"

Parameter

Layer 1/2 Parameter einstellen. Ohne Argument oder Berechtigung werden alle Parameter angezeigt.

Bei P 0 werden nur alle Systemweiten Paras angezeigt.

Bei P 1 bis P 8 werden nur die Daten des Interfaces angezeigt.

Beispiele

PARAMETER SCC 1 SMACKSTART 1

PARAMETER PORT 1 T1 20

PARAMETER PORT 4 SMACKSTART 2

PARAMETER PORT 4 T1 75

 

Man kann diesen Befehl aber auch abkürzen:

 

P P1 SMACK 1 t1 20 p4 smacK 2 t1 75

 

Auf dem logischen Port 1 und dem logischen Port 4 werden die Smacktreiber 1 und 2 gestartet(COM 4 und COM2). Dieser Befehl ist nur in der PC Version möglich.

Der T1-Timer (FRACK) wird auf Port 1 auf 200ms gesetzt, auf Port 4 dagegen auf 750 ms.

 

PARAM p4 FISS

 

PARAM p3 SIMPLEX

 

 

 

AX.25 bezogene Parameter

PARAMETER AX <portangabe> FRACK <wert in 10ms>
PARAMETER AX <portangabe> T1 <wert in 10ms>

Dieser Parameter bestimmt kanalbezogen in welchen Abständen nachgefragt wird, ob ein Paket angekommen ist.

PARAMETER AX <portangabe> RESPTIME <wert in ms>
PARAMETER AX <portangabe> T2 <wert in ms>

Dieser Parameter bestimmt kanalbezogen nach welcher Zeit die Bestätigung eines empfangenen I-Pakets erzeugt wird. dadurch läßt sich die Anzahl der unnötigen Bestätigungen reduzieren. Bei ungünstiger Wahl kann er allerdings den Durchsatz stark verringern.

PARAMETER AX <portangabe> CHECK <wert in s>
PARAMETER AX <portangabe> T3

Setzt den initialen Wert für den Timer 3 für jedes AX25 - QSO, welches auf diesem Port läuft.

Der Timer 3 läuft immer dann, wenn T1 NICHT läuft. Nach jedem gesendeten oder empfangenen Frame wird T3 zurück auf 0 gesetzt. Läuft der Timer einmal ab (also war entsprechend lang KEINERLEI QSO - Aktivität mehr), so sendet der Digi ein RR mit gesetztem Poll-Bit. Dies muß der QSO-Partner nun mit einem Frame bestätigen (meist wird das RR- sein), sofern der Partner noch da ist. So lassen sich QSOs erkennen, bei denen der Partner disconnectet hat ohne die Bestätigung des Digis abzuwarten, oder – SCHLIMM, SCHLIMM - einfach den TNC ausgemacht hat.

Empfohlener Wert: 600 (10 Minuten).

PARAMETER AX <portangabe> RNRTIMER <Wert in Sekunden>

NotReadyCheck-Parameter einstellen.

Meldet ein QSO-Partner (durch Aussendung eines RNR-Frames), daß er zeitweise besetzt ist, so werden vom Digi keine Frames mehr in Richtung des Partner geschickt. Stattdessen fragt er in regelmässigen Abständen (durch ein RR+ Frame), ob der besetzt-Zustand nun endlich vorbei ist. Dieser zeitliche Abstand wird hier eingestellt. Empfohlener Wert: 20 (Sekunden). maximal Wert: 60

PARAMETER AX <portangabe> RETRY <value>

Mit diesem kanalbezogenen Parameter wird eingestellt, wie oft der Digipeater versucht eine Antwort vom User - TNC zu bekommen.

Bei jedem Versuch wird ein Zähler um eins erhöht, der bei einer Antwort des User-TNCs wieder auf 0 gestellt wird. Überschreitet der Zähler nun den hier für den Kanal eingestellten Wert, so beendet der Digi das QSO mit einem DISC (das allerdings auch wiederholt wird, allerdings nur noch RETRY/4 mal), da der User seinen TNC entweder abgeschaltet hat, oder die Verbindung offensichtlich ZU schlecht ist.

PARAMETER AX <portangabe> MAXFRAME <value>

Mit diesem kanalbezogenen Parameter wird eingestellt, wieviel Pakete der Digipeater maximal losschickt bevor er auf eine Bestätigung des QSO-Partners wartet.

Dieser Wert ist nur der Initialwert eines QSOs, der sich pro QSO bei schlechten Verbindungen automatisch senkt, und bei besseren Bedingungen wieder bis auf diesen Wert hochschraubt. Der hier eingestellte Wert wird aber bei keinem QSO auf dem Port überschritten.

Erlaubter Eingabebereich: 1 - 7

Gute Werte:

1200er Einstiege: 1-2

9600er Einstiege: 3-7

Interlinks: 7

PARAMETER AX <portangabe> PACLEN <value>

Hiermit wird die maximale Anzahl von Bytes die ein Info-Frame enthalten kann eingestellt. In Abhängigikeit vom Parameter STOPFEN werden bei Bedarf längere Pakete auf diesen Maximalwert "gekürzt" (also auf mehrere Pakete verteilt).

Auf Interlinks sollte man diesen Wert im Interesse eines guten Durchsatzes auf 256 (dem lt. AX25 maximal zulässigen Wert) einstellen. Auf Interlinks zu NET/ROM (TheNet, TheNetNode, evtl. auch TCPIP - Knoten) kann man den Wert auf 235 senken, das hilft dem Nachbarn-Knoten etwas, er braucht dann nicht zu fragmentieren.

PARAMETER AX <portangabe> TXWINDOW <1-65520>

Hier wird für jedes QSO auf dem Port bestimmt wieviel Byte maximal zwischengespeichert wird, bevor der Erzeuger der Daten für dieses QSO (also z.B. die Mailbox mit der der User verbunden ist) durch RNR-Frames aufgefordert wird, doch bitteschön mal mit der Nachlieferung von Daten aufzuhören, bis die Daten abgenommen sind.

Bei schnellen Einstiegen kann man den Wert bis auf 2048 hochstellen, bei langsamen sind Werte um 512 Byte sinnvoll.

PARAMETER AX <portangabe> RXWINDOW <1-65520>

Dieser Parameter ähnelt dem TXWINDOW, allerdings wird der direkte QSO Partner selber durch RNRs gebremst, wenn mehr als die hier eingestellte Anzahl von Bytes gepuffert wurde.

PARAMETER AX <portangabe> IPOLL <wert>

Schwellenwert für I-Frame-Polling. Wird ein I-Frame von der Gegenstation nicht beantwortet, so muß der Digi nachfrageb, wo denn die Antwort bleibt (Polling). Dies geschieht üblicherweise durch ein RR mit gesetztem Poll-Bit. Nun ist es meistens günstiger mit einem I-Frame zu pollen, wenn der darin enthaltene Text hinreichend kurz ist. Was "hinreichend kurz" ist, läßt sich nun mit diesem Parameter einstellen. Hat ein I-Frame einen längeren Inhalt (wohlgemerkt INHALT - der AX25-Header zählt nicht mit) als hier eingestellt, so wird ganz normal mit RR gepollt.

Möglich sind Werte zwischen 0 und 255. Null schaltet das I-Polling komplett ab, d.h. es findet generell nicht statt.

Empfohlen werden Werte zwischen 15 und 40 Byte Infogehalt. Welches der optimale Wert ist, könnte mal wieder Thema eines Glaubenskrieg werden. Im übrigen wird maximal 3 mal mit einem Info-Frame gepollt. Danach wird immer mit RR-Frames gepollt.

PARAMETER AX <portangabe> UINO
PARAMETER AX <portangabe> UIALL
PARAMETER AX <portangabe> UINOAX25
PARAMETER AX <portangabe> UITXD

Hiermit können Sie bestimmen, was mit UI-Frames (z.B. Bakenaussendungen von User) passiert, die den Digi passieren.

Die normale Eistellung sollte immer und auf allen Ports UIALL sein. Dadurch werden alle UI-Pakete normal über den Digi geroutet.

Treiben auf dem Usereinstieg zu viele Benutzer Unsinn, indem Sie viele unerwünschte Bakenausstrahlung machen, so sollten Sie die Einstellung UINOAX25 wählen. Dadurch werden alle UI-Sendung die die PID 240 (dez.) tragen verworfen. Was nichts anderes heisst, daß alle Baken, die von normalen User stammen, nicht digipeated werden. Die UI-Frames anderer Protokolle (z.B. TCPIP-Datagramm Mode oder NET/ROM-Broadcast) werden aber weiterhin normal geroutet.

 

Wenn Sie diese Möglichkeit wählen, nehmen Sie den Nutzern allerdings die Möglichkeit, ihr optimales TXD durch Versuche mit UIs zu ermitteln. Wählen Sie dann UITXD. Dies hat die gleiche Wirkung wie UINOAX25, ausser daß UIs mit der PID 240 DOCH repeated werden, sofern Sie maximal ein Byte INFO-Gehalt (das Zeilenendezeiche eben) haben.

Wollen Sie alle UIs unterdrücken, so nehmen Sie die Einstellung UINO. Allerdings kenne ich keinen Fall, wo so etwas notwendig sein könnte! - Aber der Vollständigkeit halber ist dies auch einstellbar.

PARAMETER AX <portangabe> PTTNORMAL
PARAMETER AX <portangabe> PTTOFF

Mit diesen beiden Befehlen ist es möglich, die PTT dauerhaft aus zu machen (es werden dann keine Sendedaten mehr für den Port erzeugt) und sie wieder in den Normal-Betrieb zu versetzen. Das funktioniert für alle Ports, egal ob SCC, SMACK oder Loopback!

Natürlich muß man dabei sehr aufpassen, daß man nicht den Port ausschaltet, über den man selber sich in das System eingeloggt hat - eine Kontrolle vom System findet nicht statt.

PARAMETER AX <portangabe> L2DIGI <AnAus>

Via-Digipeating an/aus schalten.

Das das via-Digipeaten DAS grundlegende Konzept des von DigiWare verwendeten FlexNet-Routing ist, sollte es nur in absoluten Notfällen ausgeschaltet werden!

PARAMETER AX <portangabe> USER
PARAMETER AX<portangabe> INTERLINK
PARAMETER AX <portangabe> TERMINAL

stellt den ausgewählten Port auf den genannten Typ (z.B. p p1 USER). Nur auf einem Usereinstieg kann CQ gerufen werden, und nur hier findet das "Stopfen" Anwendung.

Auf einem INTERLINK wird das Timing etwas anders gehandhabt.

Ein Port des Typs TERMINAL ist meist mit einem Treiber für KISS & Co. oder dem Loopbacktreiber versehen.

PARA AX <nr> MINSSID <ssid>
PARA AX <nr > MAXSSID <ssid>

legt die für den aktuellen Port gültigen min. und max. SSIDs fest.

P AX <nr> MYCALL <call>
P AX <nr> MYIDENT < IDENT>

Weisst dem Digis neue Calls zu. MYCALL für Port 1 sollte immer gesetzt werden, auch wenn kein Modem daran angeschlossen ist oder kein Treiber auf Port 1 geladen wird. Einige Funktionen verlangen nämlich nach EINEM Call für den Digi (z.B. Vernetztes Convers) - und das ist dann eben das des Ports 1 (per Definition:) )

Achtung: QSO kann dabei abreißen - Bestehen noch Linkeinträge auf das ehemalige MyCall kann es merkwürdige Effekte geben.

PARA AX <nr> MAP ifnr

Hiermit wird der Port festgelegt, auf dem Connectversuche und CQs ausgegeben werden, wenn man über einen Interlink hereinkommt, der Digi aber zwei oder mehr Einstiege (z.B. 70 und 23cm) hat.

P P2 MAP 1

Alle auf P2 hereinkommenden QSOs erhalten Port 1 als Defaultportnr.

MYPACLEN <100-255>

Setzt die PACLEN nur für das eigene QSO auf diese Länge.

 

SCC bezogene Parameter

PARAMETER SCC <portangabe> TXD <value in 10ms>

TXDELAY-Parameter wird hiermit eingestellt

PARAMETER SCC <portangabe> DF9IC

Es wird ein Standard-ModemDF9IC Modem angenommen. Die weiteren Parameter werden wie folgt vorbesetzt:

CLKMOD $08 (ext. RX-Takt an RTxC, ext. TX-Takt an TRxC).

SIMPLEX normaler Simplexbetrieb mit DCD.

NRZ Datenkodierung im NRZ-Format.

Da die beiden Takte als extern konfiguriert wurden, ist eine softwaremäßige Baudratenumschaltung nicht möglich.

PARAMETER SCC <portangabe> G3RUH

Es wird ein nach TNC4 (FALCon)-Handbuch-Vorschlag 2 oder 3 angeschlossenes ModemG3RUH-kompatibles Modem angenommen. Die weiteren Parameter werden wie folgt vorbesetzt:

CLKMOD $66 int. RX-Takt, ext. TX-Takt an RTxC

SIMPLEX normaler Simplexbetrieb mit DCD

BRGOUT Der TRxC-Pin gibt das 32-fache Baudratensignal aus.

NRZI Datenkodierung im NRZI-Format

Die Baudrate ist softwaremäßig einstellbar, da der interne Baudratengenerator verwendet wird.

PARAMETER SCC <portangabe> AFSK

Es wird ein AFSK-Modem wie zum Beispiel TCM3105 oder AM7910/11 angenommen. Die weiteren Parameter werden dabei automatisch wie folgt vorbesetzt:

CLKMOD $76 int. RX-Takt, int. TX-Takt)

SIMPLEXS Simplexbetrieb mit DCD und ohne Vollduplexmöglichkeit

NRZI Datenkodierung im NRZI-Format

Die Baudrate ist softwaremäßig einstellbar, da der interne Baudratengenerator verwendet wird. Es ist kein Vollduplex vorgesehen, da beim Senden der Baudratentakt umgeschaltet wird.

PARAMETER SCC <portangabe> NRZI

Der Port sendet und empfängt die Daten im NRZI-Format (z.B. an G3RUH-Modem)

PARAMETER SCC <portangabe> NRZ

Der Port sendet und empfängt die Daten im NRZ-Format (z.B. an DF9IC-Modem).

PARAMETER SCC <portangabe> SIMPLEX

Der Port wird auf normalen Simplexbetrieb mit DCD-Abfrage eingestellt. Der Wert des Baudratengenerators wird beim Umschalten auf Sendung nicht verändert.

PARAMETER SCC <portangabe> DUPLEX

Der Port wird auf Vollduplexbetrieb ohne DCD-Abfrage eingestellt. Der Wert des Baudratengenerators wird beim Umschalten auf Sendung nicht verändert. Mit dem SIMPLEX Kommando kann bei Bedarf auch während des Betriebes auf Simplex mit DCD-Abfrage umgeschaltet werden.

PARAMETER SCC <portangabe> SIMPLSPEZ

Der Port wird auf Switched-Simplexbetrieb mit DCD-Abfrage eingestellt. Der Baudratengenerator liefert beim Empfangen den 32-fachen Takt für die Empfangs-DPLL und beim Senden den einfachen Sendetakt. Es ist daher keine Umschaltung auf Vollduplex möglich.

Setzt den Port auf Mode "spezieller Simplex-Mode". Dieser wird bei Betrieb von TCM3105, AM7911 und von externer Loopback (Schleifenverbindungen bzw. Drahtverbindungen zu anderen SCCs) benötigt.

 

PARAMETER SCC <n> CLKREG <n>

Dieses Schlüsselwort muß von einem zweiten nummerischen Parameter gefolgt werden, der den Taktmodus des SCC-Bausteines einstellt. Der nummerische Parameter muß in dezimaler Schreibweise angegeben werden. Der hier angegebene Wert wird bei der SCC-Initialisierung in das Register 11 des entsprechenden SCC-Hardwareports geschrieben. Da das Register 8 Bit breit ist sind nur Werte im Bereich von dezimal 0 bis 255 zulässig. Die einzelnen 8 Bits des Bytes haben im einzelnen folgende Wertigkeiten und Bedeutung:

 

Bitnummer

7

6

5

4

3

2

1

0

dez. Wertigkeit

127

64

32

16

8

4

2

1

hex. Wertigkeit

$80

$40

$20

$10

$08

$04

$02

$01

 

Bit 7 sollte immer auf 0 gesetzt werden, da durch dieses Bit ansonsten eine für die Anwendung von TNC4 (FALCon) nicht sinnvolle Funktion des SCCs freigegeben wird. «awenn intern=1»In der Firmware wird dieses Bit automatisch immer auf 0 gesetzt, auch wenn ein anderer Wert eingegeben wird.

Bit 6 und 5 geben an, aus welcher Quelle der Empfänger mit einem Taktsignal versorgt wird. Folgende Bitkombinationen sind möglich:

 

Bit 6

Bit 5

Quelle des RX-Taktes

0

0

RTxC-Pin des SCC

0

1

TRxC-Pin des SCC

1

0

direkt vom Baudratengenerator

1

1

von der DPLL (Taktregenerator)

 

Bit 4 und 3 geben an, aus welcher Quelle der Sender mit einem Taktsignal versorgt wird. Folgende Bitkombinationen sind möglich:

 

Bit 4

Bit 3

Quelle des TX-Taktes

0

0

RTxC-Pin des SCC

0

1

TRxC-Pin des SCC

1

0

direkt vom Baudratengenerator

1

1

von der DPLL (Taktregenerator)

 

Bit 2 gibt an, ob der TRxC-Pin als Ein- oder Ausgang geschaltet ist. Ist Bit 2 auf 0 gesetzt, wird der TRxC-Pin als Eingnag verwendet. Ist Bit 2 hingegen auf 1 gesetzt, wird über den TRxC-Pin das durch Bit 1 und 0 gewählte Signal ausgegeben, sofern der TRxC-Pin nicht als Quelle des RX- oder TX-Taktes angegeben wurde.

Unter der eben festgelegten Voraussetzung, daß Bit 2 auf 1 gesetzt ist und der RX- sowie der TX-Takt nicht vom TRxC-Pin kommen, sind durch die beiden verbleibenden Bits 1 und 0 folgende Ausgaben über den TRxC-Pin möglich:

 

Bit 1

Bit 0

Ausgangssignal am TRxC-Pin

0

0

nicht verwendet oder inaktiv

0

1

Takt des SDLC-Senders

1

0

direkt vom Baudratengenerator

1

1

von der DPLL (Taktregenerator)

 

Die EPROM Voreinstellung für das @MODEM-Kommando entspricht der Einstellung für AFSK-Modems (Switched-Simplex, NRZI, int. Takte, kein Taktausgang).

 

 

V24 bezogene Parameter

PARAMETER v24 <nr> BASE <n>

(nur PC) legt für einen Treiber (z.B. SMACK) die Basisadresse des I/O Baustein (z.B. UART) fest. <n> muß dabei dezimal angegeben werden. Beispiel:

P p3 SMACKSTART 2 io 760 IRQ 3 baud 4800 SMACKINIT

PARAMETER v24 <nr> IRQ <n>

(nur PC) legt für einen Treiber (z.B. SMACK) die Interruptrequest - Leitung fest, die der I/O Baustein (z.B. UART) auslöst. <n> muß dabei dezimal angegeben werden. Bei Hexangaben muß ein $ vorausgehen. Beispiel:

P p3 SMACKSTART 2 io 760 IRQ 3 baud 4800 SMACKINIT

P p3 SMACKSTART 2 io $3f8 IRQ 3 baud 4800 SMACKINIT

PARAMETER <portangabe> SMACKSTART Lokale_Nr_der_PC-V24

Startet auf dem ausgewählten Kanal den SMACK Treiber (KISS mit Prüfsumme). Er funktioniert analog zu P FISS mit folgenden Unterschieden:

1. SMACK Unterstützung, aber auch weiterhin KISS-kompatibel.

2. Nur in der PC-Version der Software enthalten.

 

Beispiel:

P p3 SMACKSTART 2 io 760 IRQ 3 baud 4800 SMACKINIT

 

Ansonsten gilt das bei PARAMETER FISS gesagte.

PARAMETER <portangabe> SMACKINIT

Initialisiert einen angeschlossenen TNC in den KISS Modus. SMACKSTART muß vorher schon gegeben worden sein, sowie Parmeter (Baud) für die V24. Beispiel:

P p3 SMACKSTART 2 io 760 IRQ 3 baud 4800 SMACKINIT

KISS bezogene Parameter

PARAMETER <portangabe> TXTail <value in 10ms> (KISS)

TXTail-Parameter wird hiermit eingestellt. Dies ist die Verzögerung mit der die PTT nach Aussendung des Ende-Flags abfällt.

Dieser Parameter wird zur Zeit nur vom PC-SMACK/KISS-Treiber unterstützt. Beim SCC ist TxTail (noch) fest eingestellt.

PARAMETER <portangabe> DWAIT <value in 10ms> (SCC)

Zeitverzögerung vor dem Hochtasten der PTT nachdem der Kanal frei wurde (nicht bei Duplex).

PARAMETER <portangabe> BAUD <wert> (V24,SCC)

Baudrate in Baud setzen. Initial. auch das Gerät (z.B. den FALCon SCC-Kanal) neu. Werte kleiner gleich 768 setzt die Baudrate auf den 100fachen Wert! also

BAUD 1200 ==> 1200 Baud

BAUD 12 ==> 1200 Baud

BAUD 9600 ==> 9600 Baud

BAUD 96 ==> 9600 Baud

BAUD 384 ==> 38400 Baud

BAUD 768 ==> 76800 Baud

 

PARAMETER <portangabe> SCCSTART <Lokale_Nr_der_SCC>

Startet auf dem ausgewählten Kanal den SCC Treiber des TNC4 (FALCon). Dieser Befehl sollte am Anfang des Config Files für jedem SCC Port stehen. <portangabe> ist dabei die logische Portangabe (P1 bis P8), die z.B. bei dem Befehl LINK mit ausgegeben wird und hat nichts mit den <Lokale_Nr_der_PC-V24> zu tun!

Letztere definieren die physikalische Adresse der SCCs (auf dem TNC4 (FALCon) 1 bis 4). Es ist also z.B. möglich den 1. Kanal des 1.SCC auf den logischen Port 5 zu legen:

P p5 SCCSTART 1

PARAMETER <portangabe> FISS [<0 oder 1>] (FALCons kISStreiber)

Startet auf dem ausgewählten Kanal den KISS Treiber. Er ist völlig tansparent in das System der Ports einbezogen. Man kann also mit ihm fast alles machen, was man mit einem SCC-Port machen kann. Also z.B. einen weiteren TNC4 (FALCon) anschliessen; einen PC mit NET, NOS, WAMPES oder TFPCR (und damit auch GP, SP, DieBox und alle anderen Hostmode Programme, die TFPCR unterstützen) oder auch die RMNC-KISS Karte oder PCFlexnet anschliessen.

 

Die Ausgabe der KISS/SMACK/FLEXCRC-Daten erfolgt wahlweise auf der ersten oder zweiten V24 (oder uaf beiden gleichzeitug) des TNC4 (FALCon) standardmäßig mit 9600 Baud, N,8,1 (Voreinstellung). Die KISS Baudrate ist frei einstellbar durch den auch bei den anderen Ports verwendeten Befehl Parameter BAUD. Beide Angaben können auch auf einer Zeile erscheinen

p V24 <n> baud <x> INIT

<n> steht für 1 oder 2 (v24-1 oder v24-0).

Wird FISS 0 gewählt, so ist das Debugterminal automatisch außer Betrieb gesetzt. Ein zurückschalten ist zur Zeit nur durch Reset möglich.

 

Achtung: Der Parameter FISS enthält implizit den Wert 9600 Baud als Voreinstellung.

 

p P5 baud 300 FISS 1

stellt den Wert 9600 Baud ein (und nicht etwa 300 Baud). Richtig wäre also

p P5 FISS 1 baud 300

 

Allerdings gibt es zwei Dinge zu berücksichtigen:

 

1. KISS ist nicht fehlergeschützt. d.h. man geht hier das Risiko, daß Daten verfälscht werden!). Ich rate daher zunächst von Anwendungen ab, die z.B. automatischen S&F über diese Schnittstelle machen wollen und der V24-Partner weder SMACK noch FLEX-CRC kann.

 

2. Verwendet man SMACK oder KISS, so sollten beide Partner auf jeder Seite eine minütliche Bake auf die V24 geben, damit im Falle eines Falle (der eine Partner fällt aus) nach 'nem Neuanschluss der andere Partner nicht restet werden muß (weil er im SMACK/FLEXCRC Modus ist)).

 

3. die momentane Implementierung ist nicht optimiert. Deswegen wird nach dem Start des KISS-Treibers die Systemleistung abfallen (allerdings in vertretbaren Maßen).

 

Dieser Befehl ist nur in der TNC4 (FALCon)- (und nicht in der PC-Version) der Software verfügbar (s. SMACKSTART).

PARAMETER <portangabe> LOOPSTART

Startet auf dem ausgewählten Kanal einen Loopbacktreiber. Dieser steuert kein angeschlossenes Gerät oder ähnliches, sondern schiebt auf dem Kanal empfangene Pakete sofort in die Empfangs-Queue desselben Kanals. Verwendung bei Tests und Selbstconnects.

PARAMETER <portangabe> IPXSTART Lokale_Nr_der_PC-V24

(Nur PC)

Startet auf dem ausgewählten Kanal den IPX-Treiber (Protokoll von Novell, hauptsächlich für Netzkarten).

Beispiel:

P p3 IPXSTART 3

PARAMETER <portangabe> PORTSTOP

Hiermit werden ein Port "ausgeschaltet"; er ist danach nicht mehr gültig. Es ist dabei unerheblich, mit welchem Treiber auf dem Port gearbeitet wurde.

PARAMETER <portangabe> GETVALUE <n>

Systeminterne Bedeutung (Treiber) - Nicht verwenden

PARAMETER <portangabe> SETVALUE <n>

Systeminterne Bedeutung (Treiber) - Nicht verwenden

Gesamtsystembezogene Parameter

PARAMETER UPDATE

Die wichtigsten Parameter der Ports 1-6 werden in das EEPROM gebrannt und werden nach dem nächsten Reset oder Stromausfall automatisch geladen und verwendet. Diese Parameter sind:

Treibertyp und Nr.; Baudrate; Modus(Simplex/Duplex); UI-Repeat-Modus; TX-Delay; L2-Digipeating Modus; Min- und Max-SSID; NRZI- und CLK-Einstellung; PTT-Modus; DWait; FRACK; Retries; Call (aber nicht das IDENT!); Mapping.

Hinweis: Bei Verwendung des BIG-EEPROMs (24c65) ist dieser Befehl wirkungslos, da ein anderer Mechanismus dort zustande tritt (s. WRITE)

PARAMETER OLDPARA

Gegenteil von UPDATE. Macht die im EEPROM enthaltenden Daten ungültig. Nach einem Reset oder Stromausfall werden daher wieder die eingepatchten Parameter verwendet.

Hinweis: Bei Verwendung des BIG-EEPROMs (24c65) ist dieser Befehl wirkungslos, da ein anderer Mechanismus dort zustande tritt (s. WRITE)

PARAMETER EWRITE <Text>
PARAMETER EREAD

Dies beiden Befehle dienten nur zum Debuggen der EEPROM. Sie können jederzeit in einer neuen Version wegfallen( - Und sind es auch seit der Version 0.84h...)!

Mit EWRITE wird ein maximal 120 Byte langer Text in den EEPROM geschrieben. Dabei werden alle mit P UPDATE eingespielte Daten gelöscht. Mit EREAD kann man diesen Text (oder jeden anderen EEPROM Inhalt) wieder auslesen.

PARAMETER DNCALLCHECK <AnAus>

Rufzeichenprüfung bei Connect Befehlen aus der Infobox hinaus Aus/Ein.

PARAMETER UPCALLCHECK <AnAus>

Rufzeichenprüfung Aus/Ein (gültiges Call muß beim Uplinkenden gesetzt sein)

PARAMETER SMOOTHFRACK <AnAus>

Dynamisches Setzen von T1 an/aus. Wenn ausgeschaltet wird (P SMOOTH OFF), werden alle dyn. Parameter aller QSOs auf die Initwerte zurückgesetzt.

PARAMETER FINDRETRY <Wert>

Anzahl der UIs die pro Weg beim Auslösen des FIND Kommandos abgeschickt werden. Maximalwert: 50.

FLAG ROUTEUNKNOWN <AnAus>

Hiermit wird das Verhalten des Digis beim Empfang von nicht zu einem im Digi geführtem QSO gehörigen Frames (ausser SABM und UI) eingestellt.

AN bedeutet, daß die Frames einfach durchgeroutet werden, während bei AUS die Frames verworfen werden, bzw. mit DM beantwortet werden, wenn es ein Poll-Frame war.

In der Stellung AN werden also auch nach einem Reset der Software bestehende QSOs nicht getrennt, sondern laufen weiter, wenn auch nicht mehr im Hop2Hop Verfahren. In Einzelfällen kann es dabei prinzipbedingt zu FRMR kommen.

Die Einstellung dieses Parameters kann im EEPROM gespeichert werden (s. PARAMETER UPDATE), da er grade nach Resets relevant ist. Der Defaultwert ist AN.

PARAMETER INFOBOXTIMEOUT <min>

TIMEOUT-Zeit der Infobox einstellen (Sysops fliegen nicht raus). Nach 2/3 der Zeit erhält der User eine Warnung. Übrigens: Timeouts von unter einer Stunde sind absolut nicht sinnvoll. Sie stören nur das "DXen". Auch sonst hat ein Timeout keinen besonderen Sinn: "Hängende QSOs" werden durch T3 erschossen, außerdem ist genügend Speicher für eine hohe Anzahl von QSOs vorhanden; ein QSO wo nichts passiert braucht eh kaum Ressourcen (HF-Bandbreite, Speicher, Rechenzeit).

Mindestwert: 45 Minuten

Default: 4 Stunden.

PARAMETER NRHINT <AnAus>
PARAMETER NETROM <AnAus>

An/Ausschalten der Verwendung von empfangenen -Routing-Broadcasts. DEFAULT: An. (Das Alias NRHINT wird demnächst entfallen). S.a. NRC

PARAMETER DIGISEARCH <AnAus>

Schaltet den FIND Befehl an und aus. Ist er ausgeschaltet erhält jeder, der FIND eingibt einen entsprechenden Hinweis.

PARAMETER BOXIFACE BOXPFAD

Weg und Portnr. zur nächsten Box. Wird bei Eingabe des Befehls M angewendet. Es geht per Autorouter.

Achtung: BOXP muß der letzte Befehl in der Parameter Zeile sein, alles was danach kommt wird als ganzes als Pfad gespeichert.

P BOXI 2 BOXP DK0MWX v DB0BM

PARAMETER MYNAME <Digi-Bezeichnung>

Analog zu den aus den BayCom-Digipeatern bekannten Namen, lässt sich hiermit ein Name (meist die Ortsbezeichnung des Digis) für den eigenen Digipeater festlegen. Er wird dann automatisch den benachbarten BayCom-Digipeatern mitgeteilt.

Die <Digi-Bezeichnung> darf nur aus Grossbuchstaben und Zahlen bestehen. Insbesondere Leerzeichen sind nicht zulässig. Maximale Länge sind 9 Zeichen.

Beispiel:

PARA MYNAME SOLINGEN

PARAMETER MYQTH locator

Hiermit wird das eigene QTH festgelegt. Wird für die QTH Kennerberechnung verwendet. s. Befehl QTH

PARMETER RPS

Initialisiert die RPS - Messung neu. Wozu weiss ich nicht, aber es wollte wer so.

PARAMETER REORG

zum händischen Kürzen der Zieleliste. Ausgegeben wird

*** a/b

wobei a/b gleich Anzahl der Ziele vor/nach der DestinationReorganisation ist. Im normalen Betrieb NIE notwendig.

PARAMETER DISPFRAME on/off

Gleiche Funktion, wie CTRL-N im Debug-Interface; stellt die Ausgabe der Monitordaten auf der V24 an oder aus.

Recht nützlich, wenn man auf dem Turm war und vergessen hat, den Monitor abzustellen; bei zu kleinem COM-Puffer wird der Digi dann nämlich langsam.

PRIV xxxx

sich als SYSOP kennzeichnen (wie bei DIEBOX).

Das Passwort besteht aus 4 Zeichen, die von der Uhrzeit und dem Datum des Logins in DigiWare abhängen. Im Passwortfile (am besten nimmt man PW.TXT, dies wird von einigen Terminalprogrammen unterstützt) wählt man die SPALTE, die den STUNDEN des Logins entspricht. Für die ZEILE ist diejenige maßgeblich, die den MINUTEN entspricht.

Von diesem Punkt in der Tabelle wandert man nun so viele ZEILEN herunter, wie TAGE im Login-Datum angezeigt werden. Beim Datum "23.08.92" wandert man also 23 Zeilen herunter, dabei aber immer in derselben SPALTE bleiben. Beim Erreichen des Tabellenendes macht man einfach in Zeile "0" weiter. Das Zeichen an dieser Stelle zusammen mit den drei nachfolgenden (waagerechten) Zeichen bilden das Passwort. Dabei ist darauf zu achten, daß nach Gross- und klein Schreibung unterschieden wird.

Man kann 5 mal versuchen sich einzuloggen, es muß nur ein Versuch davon richtig sein. Jeder weitere Versuch (auch mit den richtigen 4 Buchstaben) wird erfolglos bleiben, dafür aber in das DigiWare Logbuch eingetragen.

Viele Terminalprogramme (GP, SP, etc) können das Passwort auch automatisch erzeugen, dazu muß allerdings im Connecttext (wie bei DieBox) das Datum und die Uhrzeit auftauchen. Dies bewerkstelligt man, indem man mit P CTEXT das Makro %l verwendet:

P CTEXT - DB0ME - Digi/Box Solingen - JO31ME%n Login:%l%n

(das %n ist ein Makro für NEUE ZEILE). Das weitere ist im Handbuch des jeweiligen Terminalprogramms (Stichwort Sysop-Login DieBox) nachzulesen. Bei GP 1.61 muß beispielsweise eine Datei mit dem Namen des Digis, evtl. dem SSID und der Extension GPW vorhanden sein (z.B. DB0ME.GPW oder DB0IZ9.GPW)

SYsop xxxx$TODO

Diese erweiterte Funktion ist eine Variante des altbekannten TheNet Login. Es ist m.E. die z.Zt. sicherste Login-Methode eines Digi/Box-Systems das ich kenne. Auch 100faches Mitspannen eines Loginvorgangs kann nicht zur Entschlüsslung führen.

Möchte man sich also einloggen, so schickt man SYSOP an den Digi. Dieser antwortet z.B. mit

 

SG:DB0ME> 123 43 234 2 23

 

nun schaut man in der von PWGEN.EXE erzeugten Liste nach, und gibt die unter der jeweiligen Nr. angegeben Buchstaben ein. Vor und nach diesen 5 Buchstaben dürfen und sollten! weitere zufällige Buchstaben und Zahlen eingegeben werden (bis zu insgesamt 80 Stück), so dass der eigentlich Antwortstring nicht mehr trivial für einen Mitleser erkennbar ist. Durch die grosse Grundmenge (1600 Zeichen) dürfte ein Knacken durch Mitlesen ziemlich schwer sein (im Gegensatz zu anderen Systemen, wo 1 - 3maliges Mitlesen reicht...).

Der bis zu 80 Zeichen lange Antwortstring wird also zurückgeschickt, und man ist autorisiert ... oder auch nicht.

KILL <QSONR>

Schmeisst ein QSO ab. Die zugeh. Nr. ist per "U XL" oder "T ." zu ermitteln. Es ist die Nr. in der jeweils ersten Spalte der genannten Befehle

UPLoad

Programm hochladen, mit der AutoBin Methode, die auch in GP, THP, DieBox, PacketMaster(Atari), SP .... Verwendung findet. Allerdings verwendet DigiWare ein eigenes zusätzliches (und sichereres) CRC-Verfahren. Die genannten Programme können trotzdem problemlos verwendet werden.

Zum Uploaden muß genug freier Speicher auf dem FALCon sein (512k oder mehr); es muß die EPROM Version laufen.

s.a. RESET

DOWNLOAD [Länge]
FAKE

Diese beide Befehle dienen zum Testen von Geschwindigkeit und Datensicherheit. Es werden hiermit ein Autobin-Übertragung vom (DOWNLOAD) bzw. zum Digi (FAKE) angestossen. Die übertragen Daten sind dabei bedeutungslos (sie werden bei FAKE vom Digi direkt verworfen); es interessiert ja lediglich Übertragungszeit und CRC.

RESTART <Anzahl>|DoIt
RESET <Anzahl>|DoIt

Upgeloadetes Programm oder Code im EPROM neustarten.

Ist das Upgeloadete Programm beschädigt (dies wird automatisch über eine interne Prüfsumme erkannt) wird auf jeden Fall das Programm im EPROM gestartet.

In <Anzahl> wird festgelegt wie oft das upgeloadete Programm resetten darf (z.B. durch Laufzeitfehler), bevor wieder auf das EPROM umgeschaltet wird. Dadurch sind auch upgeloadete Programme, die völlig fehlerhaft sind und deshalb nicht aus dem Kreuz kommen, für den Digi ungefährlich. Er schaltet früher oder später wieder auf den EPROM (mit einer korrekten Software-Version) zurück.

Wenn <Anzahl> gleich 0 ist, wird auf jeden Fall das Programm im EPROM gestartet.

Ist als Argument "DoIt" (Klein/GroßSchreibung beachten!) angegeben, wird das Programm angehalten. Die Watchdog schlägt dann zu.

Exkurs: Wie lade ich DigiWare in den FALCon (Upload)

(mindesten 512k RAM erforderlich!)

 

* QSO mit dem Digi aufbauen
Entweder normal via PR und Transceiver oder per V24 und TFPCR oder TFSMACK mit GP (o.ä.). Dann muss aber FISS im FALCon an sein (z.B. "P Port 6 FISS")

 

* Sicherstellen dass die EPROM Version von DigiWare im FALCon läuft: Überprüfen mittel TECH: In der letzten Zeile darf dann nicht

ER+

stehen (d.h. EPROM Vorhanden, Remote geladenes Programm vorhanden, Remote Pgm. Läuft), sondern etweder

+Er

(Kein Remote vorhanden) oder

+ER

(Remote vorhanden, aber EPROM-Version läuft)

 

* Sollte die Remote Version laufen MUSS auf EPROM umgeschaltet werden:

RESTART 0 (SYSOP-Befehl!)

Dabei werden alle QSO abgebrochen!.

 

* Läuft (nun) der EPROM, so gebe man

UPLOAD (SYSOP-BEFEHL)

ein. Der Digi Antwortet nun mit

*** start upload

 

* Nun kann man mit AUTOBIN Upload starten. Das muss dann der fd.EXE-File sein, der mit PARCOMP.EXE und dem Loader behandelt worden sein (s.a.Seite *).

Stimmt prüfsumme etc. nach dem Upload, gebe man nun

RESTART 17

ein. Dies bedeutet das auf die Upload-Version umgeschaltet wird. Die Zahl 17 ist ein notwendiger Parameter, der >0 sein muss. Zur näheren Bedeutung siehe Seite *.

 

TIP:

Nach dem Hochladen einer neuen DigiWare Version sollte man unbedingt einmal den FALCon connecten und irgendwas abrufen! Denn wenn 15 Minuten nach dem Hochlaufen der Software kein Connect MIT Infoframe-Austausch zustande kommt, schlägt eine SoftwareWatchdog zu und schaltet SOFORT auf EPROM - Betrieb zurück! Das ist deswegen sehr sinnvoll, wenn ein Programmier- oder Parametrierfehler (z.B. die falschen Modems eingetragen) vorliegt!

SETDate ddmmyyyy

System-Datum setzen. Das Argument ist ohne Punkte einzugeben.

SETD 31101991

SETTime hhmm

System-Uhrzeit setzen. Das Argument ist ohne Punkte einzugeben.

SETT 1230

SYSBusy [ <minuten> [ <portnr> ]]

System nimmt <Minuten> lang auf Port <portnr> keine SABMs mehr an, sondern stellt sich busy. Nach MINUTEN geht er automatisch wieder in den akzeptierenden Zustand über. Ist die Minutenangabe = 0 so wird auch vor der eingestellten Zeit SABMs wieder akzeptiert.

Fehlt die Portangabe werden alle Ports geperrt. Fehlen alle Angaben wird die augenblickliche Einstellung angezeigt. Um den Port 1 (normalerweise ist das der Usereinstieg) 20 Minuten lang zu sperren, gebe man

SYSBUSY 20 1

ein.

Tech [arg]

Techniche Daten.

Wird eine Nr. mit einem Punkt dahinter angegeben ("TEC 12."), so kommen die Daten aus dem entsprechenden QSO; bei TECH . aus allen QSOs.

 

ERRor [arg]

Liste zur Fehlersuche in DigiWare. Diese Daten sind wirklich nur für Entwickler von Interesse.

«awenn devel» Wenn man als ARG 1 angibt ("ERR 1"), so erhält man statt der Statistik-Angaben zum Programmstatus den evt. recht umfangreichen Stackdump.

 

Wie sucht man Fehler / Wie man aus dem ERR-Listing auf die Stelle im Source kommt:

Man benötigt dazu den MAP-File (wird vom Compiler erzeugt - Option-Linker-Map detailed).

Dann nimmt man sich aus der entsprechenden Stackdump-Zeile den zweiten Hex-Eintrag (der in der form SSSS:OOOO z.B.: 03f2:26e6 )

Einfach nun nachsehen (am Anfang des Map Files) zu welcher Unit das Segment gehört. Dann im Map-File diesen Namen suchen; dort sind dann die Offsets mit den zugehörigen Zeilennr. aufgeführt.

 

INTTBL: Jede Minute werden die ersten 1024 Bytes (0:0 - 0:400 die Interrupttable halt) mit ihrem ursprünglichen Inhalt verglichen, wenn ungleich kommts ins Logbuch. Dient zur Auffindung von NIL-Fehlern. Ein Eintrag hier deutet nicht immer auf einen Fehler hin. Das Einschalten des FISS-Modes führt beispielweise zu einem Eintrag. Das ist korrekt da dabei ein Interuptvector geändert wird.

 

COUNT [argument]

Gibt ähnlich TECH und ERR Systemzähler aus, die zum Debuggen verwendet werden. Aurch Argument kann die Ausgabe eingeschränkt werden. Dabei werden dann nur solche Zähler ausgegeben, deren Beschreibung den Text <argument> enthalten. Da diese Ausgabe nur für Programmierer interessant ist, weise ich diese hiermit auf die Quelltexte hin (Gloablae

TELL <call> <Text>
TELL BROADCAST <Text>

Sendet <Text> an <Call> irgendwo im Digi.

Damit kann man auch IN ein laufendes QSO einbrechen. - Also Vorsicht!

Wenn das eine S+F Verbindung ist, haut man mitten rein. Und das steht dann in Klartext mit eigenem Call und den des Digipeaters in der Mail von irgendwen oder an alle :-)))

In fast allen Fällen kann man besser den Kommandozeilen-Talk machen - einfach nur

<call> <Text>

also z.B.

DL1EBQ Moin Moin, stell Frack ma runter

 

Bei BROADCAST statt <Call> wird <Text> an alle im Digi eingeloggten Benutzer geschickt wird (BROADCAST muß ausgeschrieben werden!). Dies ist während S&F (was auf jedem Digi fast immer irgendwie durchläuft) noch tödlicher für das eigene Image.

Texte

WRIte [CDIR] [HIDDEN] <textname> [<titel>]

Schreiben eines beliebigen Textes, der dann mittels

READ <textname>

wieder ausgelesen werden kann.

Bei Verwendung des grossen EEPROMs (24c65) hat dieser Befehl eine Sonderbedeutung (s.u.)

Die Option CDIR bewirkt das automatische Anzeigen des Directory-Eintrags nach dem CTEXT.

Die Option HIDDEN bewirkt das dieser Text bei DIR dem normalen User nicht angezeigt wird.

Mit <Titel> kann ein zusätzlicher erkärender Text angegeben werden. Er wird bei DIR und ggf. im CTEXT ausgegeben. Die Namen

 

AKT Aktuelles

INFO Informationen

HELP Hilfe

CVHELP Hilfe für Converskommandos

CTEXT Wird beim Connecten ausgegeben. Es ist auch möglich danach weitere CTexte auszugeben, die Port abhängig sind: CTEXT1-CTEXT8 heissen diese (s.a. PARAMETER CTEXT Seite *).

BYE Verabschiedung

HELP_x Diese werden auch bei Verwendung von HELP x ausgegeben; so kann man also ein komplettes Hilfesystem erstellen: HELP_LINK wäre ein Text der bei Verwendung von HELP LINK ausgegeben wird (READ HELP_LINK geht natürlich auch).

 

Beendet wird das Schreiben des Textes mit Control-Z (bzw. ***END - letzteres fkt. aber noch nicht richtig). Beispiele:

WRITE CDIR AKT A)ktuelles zu DB0ME

WRI Hardware

WRIte HELP_LINK

write HELP_CONNECT

Wri CTEXT3

TIPS:

* Um in DIR ein anderes Datum als das aktuelle anzuzeigen, einfach kurzzeitig das Datum umstellen (s. SETTIME, Seite *)

* Es sollten nicht zu viele oder zu grosse Texte geschrieben werden, da sie wg. der relativ einfachen Implementierung recht speicherbelastend sind.

* Mittels CTEXT kann man über DIR auch die Anzahl der Connects feststellen; sogar nach Ports getrennt.

 

Der Befehl WRITE EEPROM führt zum Beschreiben des EEPROMs, sofern der 64k Typ vorhanden ist. Beim Neustart des FALCon, werden die dort gespeicherten Zeilen dem Kommandointerpreter zugeführt und im Sysop-Modus ausgeführt. Dies hat also denselben Effekt wie ein CFG-File, nur daß dafür kein Upload oder EPROM-Brennen notwendig ist. So können einfach Änderungeen an Parameter, Links etc. gespeichert werden. Lediglich das Schreiben von Texten ist nich möglich, leider.

Der "PseudoText" EEPROM wird in DIR nicht aufgeführt.

Bei dem kleinen EEPROM-Typen ist weiterhin der Befehl PARAMETER UPDATE zuständig; bei WRITE EEPROM erhält man dann eine Fehlermeldung.

Die Unterscheidung, welcher EEPROM vorhanden ist, übernimmt DigiWare selbstätig.

s.a. READ EEPROM

DElete <textname>

Löscht einen mit WRITE erfassten Text

REname <alt_name> <neu_name>

Umbenennen eines mit WRITE erfassten Textes.

PARAMETER CTEXT Text

Text wird beim Connect ausgegeben, im Gegensatz zu WRITE CTEXT werden hier auch Makros expandiert. Es gelten die gleichen Makros wie bei PROMPT (s.Seite *). Ist ein CTEXT mittels WRITE erstellt worden, so wird dieser Text im Anschluss an diesen Text ausgegeben. Und im Anschluss daran werden die Portbezogenen Texte ausgegeben (das sind die mit WRITE CTEXT1 etc. erstellten).

PRompt [<string>]

Der Prompt kann hiermit geändert werden. Dabei werden Zeichenketten, die mit % beginnen durch andere ersetzt (sog. s).

%0 verhindert grundsätzlich die Aussendung eines Prompts (weshalb auch immer)

%a Dauer des Logins in Minuten

%c das Call des Users,

%d das Call des Digipeaters,

%i das Ident des Digipeaters,

%l Loginzeit

%n Zeilenumbruch (war früher mal "\n")

%s das SSID des Digipeaters,

%t in die aktuelle Uhrzeit in Stunden, Minuten,

%z die Zeitzone, in der die Uhrzeit eingestellt ist. Ist normalerweise immer "Local" (Ortszeit); bei der in Vorbereitung befindlichen DCF-Steuerung wird sich dies dann aber automatisch in "MEZ" bzw. "MESZ" (evtl auch GMT) ändern.

 

Beispiel:

PROMPT %c de %d%s (%t Local)->

ergibt als Prompt

DG9EP de DB0IZ-9 (21:05 Local)->

 

Tip:

Gerade bei PROMPT braucht man oft lange Eingabezeilen. Bei GP z.B. kann man dann tricksen (denn GP will normal keine Zeile mit mehr als 80 Zeilen). Man verwende die undokumentierte Tastenkombination CTRL-ENTER:

 

PROMPT Gleich gibt es wieder einer der <CTRL-ENTER>

beliebten Software updates! %n %c de %d%s (%t Local)-> <ENTER>

 

Hinweis:
Einige Terminal Programme interpretieren womöglich die %-Makros selber für ähnliche Zwecke. Das sollte vom Sysop bedacht werden, wenn er z.B. Parameter Files für den Upload erstellt.

Tip:
Möchte man den Digi warten oder ähnliches, so empfiehlt es sich, neben TELL BROADCAST eine Ankündigung im Prompt! Diese wird im Gegensatz zum CText auch an Rückkehrer (aus anderen Digis) ausgegeben.

Systemmanipulation

DUmp seg:ofs

Ausgabe der Speicherstellen ab seg:ofs (in Hex). Es werden etwas 80 Bytes im kombinierten HEX / ASCII-Dump ausgegeben. Wird normalerweise nicht benötigt. (USE WITH CARE)

POKE ssss:oooo wert

Schreibt einen beliebigen Wert byteweise an die Adresse ssss:oooo. Wird normalerweise nicht benötigt. (USE WITH CARE). Dabei ist <wert> per default dezimal, SEGMENT:OFFSET aber hex!

Beispiele:

POKE 1234:4567 27

POKE 2345:0000 $40

INPut <adr>

Ausgabe des Inhalts des CPU-Ports adr (in Hex). Genau ein Byte. Wird normalerweise nicht benötigt. (USE WITH CARE)

Output <adr> <wert>

Gibt <WERT> (hex) auf CPU-Port <WERT> aus Wird normalerweise nicht benötigt (USE WITH CARE)

PARA IO <n> [wert]

Hiermit wird der Zustand der Ausgangsleitung P03 bis P07 angezeigt und geändert. <n> kann dabei von 3 bis 7 sein. Ist Wert = 0, so wird die zugehörige Ausgangsleitung auf logisch 0 gesetzt. Ist der Wert ungleich 0 so wird sie Leitung auf 1 gesetzt. Danach wird der aktuelle Zustand dieser Leitung nochmals gelesen und ausgegeben. ("IO:1" bzw "IO:0"). Wird kein Wert angegeben, so erfolgt nur die Ausgabe des aktuellen Zustands.

Noch nicht voll getestet. Aufgrund vom WriteOnly Status der zugehörigen Mode-Register kann z.Zt. ein EINGANG plötzlich AUSGANG werden (und umgekehrt)!!! ---> (USE WITH CARE)-

Achtung! Nicht mit IOBASE der PC-Version verwechseln!!

PARA AD n [wert]

Hiermit wird der Zustand der Analog/Digitalwandler/Eingangsleitung PT0 bis PT7 angezeigt. n kann dabei von 0 bis 7 sein. Als Ausgabe erhalten Sie einen Wert zwischen 0 und 16. Die Werte von 0..16 stellen kodiert die Spannung auf der Eingabeleitung dar:

Vx = VTH * n/16

Vx ist die gesuchte Spannung, VTH die am gleichnamigen Pin angelegte Referenzspannung (diese sollte 5 Volt nicht übersteigen), n ist der Wert der von DigiWare ausgegeben wurde.

Beispiel: 5 Volt angelegt; Antwort auf

MUellen <anzahl>

DIESER BEFEHL IST SEIT DEM 7. NOVEMBER 1993 NICHT MEHR VORHANDEN!.

Vorher gab er <anzahl> mal die Zeile "TEST (<nr>)" zurück. Ist für Tests vorgesehen.

Flexnetrouter

(in TermWare nicht enthalten)

Der Flexnet kompatible Router in DigiWare ist komplett neu implementiert worden. Es wurden keinerlei fremde Sourcen o.ä. verwendet. Das hat zur Konsequenz, daß der Router in manchen Situationen möglicherweise anders reagiert als die RMNC oder BayCom - Implementierung.

PARAMETER LZMESS <AnAus>

Laufzeit-Messen generell an und ausschalten. Gilt auch für Messungen zu "Dumm"-Digis. Wird normalerweise nicht gebraucht. Standardeinstellung: AN

PARAMETER FLEXNET <AnAus>

FlexNet-Router an/aus. Wird normalerweise nicht gebraucht. Standardeinstellung: AN

PARAMETER TXDEst <AnAus>

Weitergeben der Destination-Tabelle an Nachbar-Digipeater, die Flexnet beherschen (DigiWare, BayCom, SNet, RMNC). Standardeinstellung: AN

 

DESTList [arg]
D* [arg]
D [arg] *

gibt die komplete Routingtable aus, evt. durch ARG eingeschränkt. Es können also sehr viele Daten dabei herauskommen. So typischerweise 300 Zeilen oder so. Die Ausgaben haben für den Sysop keine praktische Bedeutung. Beispiel:

 

44. DB0DA 0- 7 9I * 1104 884 913 2857 0 0 * 00000000 48719593 155123

 

44. Laufende Nr. innerhalb der Tabelle. Dieser Wert ist nicht konstant.

DB0DA Call (ohne SSIDs)

0- 7 SSID-Bereich

9I Link-Nr. der verwendeten Route. Einfache Abfrage welche Ziel über einen bestimmten Link geroutet wird durch DESTL <linknr>I

* 1104 884 913 2857 0 0 *
Laufzeiten zu diesem Ziel via den Links (können auch negativ sein!)

00000000 Update-Info (Bitfeld)

48719593 Update Zeitpunkt

155123 Zeit, die seit dem Updatezeitpunkt verstrichen ist.

 

TBL [arg]

Laufzeiten aller Links (S:Schnitt; T:Their; O:Our; 16 pro Link). Kein Sysop Befehl, aber undokumentiert für User.

Hiermit kann man sehr schön die gemessenen Laufzeiten kontrollieren; die Einträge in der Linkliste stellen ja nur einen Schnitt da.

PARA MINFLEXSSID <ssid>
PARA MAXFLEXSSID <ssid>

legt fest mit welchem maximalen SSID der Digi bei Flexnetpartnern eingetragen wird. Die hier eingegebenen Werte sollten sorfältig gewählt werden, um Überschneidungen zu vermeiden. Beispiel:

 

P Minflexssid 0 MaxFlexSSid 10

 

Dieser Befehl könnte in zukünftigen Versionen entfallen.

Link [argument]
Link [ LIST | ADD | INS | CHG | DEL ] [ZIEL <Ziel>] [VIA <call>] [PORT <wert>] [NR <nr>] [MAXSSID <ssid>] [HIDDEN|PUBLIC] [[NO]MEASURE]] [NETROM | FLEXNET | TCPIP | BOX] [<text>]

LIST (oder PORT als Synonym) zeigt und ändert alle oder einige Einträge der Linkliste. Anhand dieser Linkliste bestimmt DigiWare, wohin SABMs und UIs zu senden sind.

Um zu kontrollieren, ob und wie gut die Strecke zu einem eingetragenen Ziel ist wird regelmässig ein Connectversuch zu diesem Ziel gestartet.

Eine User kann sich lediglich alle Digis auflisten lassen. Dabei ist durch das optionale Argument eine Einschränkung möglich. Ist es angegben, so werden nur die Einträge ausgegeben, in denen das Argument textuell vorhanden ist. So listet

LI DB0

alle Digipeater auf die DB0 im Rufzeichen (oder im Text) haben.

L P3

listet die Einträge auf, die sich auf Port 3 beziehen.

 

ADD
INS

Als Sysop trägt man hiermit die Links ein, ändert und löscht sie.

LINK ADD Port 2 Ziel db0iz NOM

Trägt DB0IZ als direkt über Port 2 erreichbar ein. Eine Laufzeitmessung findet nicht statt.

 

CHG

Mit CHG lassen sich die Einträge ändern. Als Argument ist NR notwendig (um die Nr. festzustellen vorher einfach als Sysop mal LINK aufrufen). Durch die Verwendung der Schlüsselworte Ziel, HIDden, PUBlic, MEAsure, NOMeasure, NETROM, FLEXNET, TCPIP, BOX lässt sich die entsprehende Eigenschaft des Eintrags ändern:

L CHG Nr 5 PUB MEA

zeigt Link Nr.5 in der Linkliste für User an und schaltet die Laufzeitmessung dorthin ein.

 

DEL

Löscht einen vorhandenen Eintrag. Als Argument ist NR notwendig. Hängt von dem angegebenen Link ein andere Linkeintrag direkt ab, so wird dieser Eintrag automatisch auf einen direkt Port gesetzt und ggf. FlexNet-QSO und die Laufzeitmessung dorthin unterbunden. Beispiel:

LINK DEL NR 15

 

ZIEL <call>

gibt das Call des Nachbarn an.

 

PORT <portnr>

gibt den Port an, über den der Nachbar erreicht werden kann.

PORT darf nicht zusammen min VIA verwendet werden.

 

VIA <call>

gibt den Weg zum Nachbarn an. <Call> ist dabei genau ein Call das bereits als Ziel in der Linkliste steht (ggfs. mit SSID!).

VIA kann nicht zusammen mit PORT verwendet werden.

 

NR <nr>

Wird zusammen mit DEL oder CHG verwendet. <nr> ist die Nr. des Linkeintrages, der geändert / gelöscht werden soll. Er lässt sich als Sysop durch Eingabe von LINK <call> ermitteln,

 

MAXSSID <ssid>

Dieser Befehl setzt die obere SSID eines Linkeintrages. Bei Flexnet-Partnern wird dieser Wert automatisch während des Linkaufbaus (des InternodeQSOs) ermittelt und sollte daher nicht verwendet werden.

Bei nicht FlexNet-kompatiblen System kann es aber u.U. nötig werden dieses per Hand vorzunehmen. Ist dieser Wert hier kleiner als der im Call genannte, so werden die Werte automatisch getauscht. Beispiel:

L A Z DB0DUM-7 port 2 maxssid 2

hat dieselbe Wirkung wie

L A Z DB0DUM-2 port 2 maxssid 7

nämlich (in der Linkliste):

DB0DUM 2-7 P2

 

HIDden
PUBlic

Wenn ein Eintrag HIDDEN ist, so wird er dem Normaluser nicht angezeigt.

PUBLIC zeigt einen vorher mit HIDder versteckten Eintrag jedem wieder an.

 

MEAsure
NOMeasure

bestimmt ob zu dem Nachbarn eine LZ-Messung durchgeführt wird.

 

NETROM
FLEXNET
TCPIP
BOX

Stellt das System des Nachbardigis ein. Diese ist lediglich für die Ausgabe durch LINK bestimmt und hat keine weiteren funktionale Bedeutung. Tritt DigiWare mit einem anderen Flexnet-kompatiblen Nachbarn in Verbindung (DigiWare, RMNC/FlexNet, BayCom oder SNet), so erkennt er diese selbstätig und trägt das korekte System ein.

 

Beispiele:

 

LINK ADD ZIEL db0qt PORT 1 "Mayen bei Koblenz"

LINK ADD ZIEL db0lj VIA db0qt "Kruft"

l a z db0zdf v db0qt "ZDF, Mainz"

 

Will man eine Laufzeitmessung zu Boxen des Types DieBox gemacht werden, so sollte dessen Sysop mittels SETUSR <digicall> <digicall> 2 den Digipeater als User sperren, damit die Box nicht unnötigt blockiert wird. Die Laufzeitmessung funktioniert trotzdem.

Convers

Konferenzmodus, wie von anderen Digisystemen bekannt. Hier ist er allerdings erheblich erweitert worden.

Im Folgenden nun die speziellen Sysop-Kommandos dazu

/FORCE <call>

(Nur im Conversmode) Zwingt Call auf den eigenen Convers Kanal; auch wenn derjenige schon auf einem anderen Convers Kanal ist. Es können nur Stationen geforced werden, die sich im Digi selber befinden (und nicht die per vernetztem Convers reinkamen) und sich nicht weiterconnected haben.

/CON <call>

(Nur im Conversmode - Kein reiner Sysopbefehl, aber nicht dokumentiert) Zwingt Call auf den eigenen Convers Kanal indem er vom Digi connectet wird. Andere Digis werden durch ein Q oder ein B im ZwangsCTEXT des Digis sofort wieder abgeworfen. Da es aber trotzdem immer wieder zu unerfreulichen Spielereien seitens der Looser kam ist seit der 0.78.1226 es nur noch möglich Stationen auf mit Userport gekennzeichneten Kanälen zu connecten.

 

TIP:
Braucht man einmal für Tests eine Datensenke (also etwas, wo man Daten schadlos hinschaufeln kann, ohne Reaktionen auszulösen oder Speicherplatz zu verbrauchen) so ist ein LEERER Convers Kanal der ideale Platz dafuer. WRITE ist dafür völlig unbrauchbar! Im Convers wähle man sinnvollerweise einen Kanal wie 99, damit sich keine andere Station dazugesellt :-)

Man kann allerdings auch eine AutoBin - Übertragung machen. Man wähle dazu den Befehl FAKE aus der Infobox.

Vernetztes Convers (ConversD)

(in TermWare ist die Vernetzung nicht enthalten)

ConversD nach DK5SG/DC6IQ wird von DigiWare unterstützt. Lediglich das autmatische Connecten der Nachbar-Hosts ist noch nicht eingebaut.

Vernetztes Convers ist, vereinfacht gesagt ein Protokoll, was dafür sorgt, daß alle angeschlossen Digis sich anscheinend einen grossen Convers teilen. Jede Station auf einem Kanal im Convers eines Digis nimmt auch gleichzeitig an dem Convers auf demselben Kanal anderer Digis teil. Näheres s. Anhang, Seite *.

PARAMETER CVCONNECT <AnAus>

Convers-Connect möglich an/aus. Diese Funktion verhindert die Anwendung des Convers Kommandos /CONNECT seitens der Anwender.

Dies ist leider manchmal notwendig, denn der Spiel-, Alber- und ErfindenVonUnsinn-Trieb der Anwender ist manchmal unglaublich.

/CONHost <cvHostCall>

(Nur im Conversmode - Kein reiner Sysopbefehl aber nicht dokumentiert) Versucht CALL, der ein gültige CVHOST sein muß, zu connecten.

Befehl wird entfernt, sobald automatisches connecten (auf Zeitbasis) implementiert ist.

PARAMETER CVHOST <Calls>

<Calls> werden als ConversHost betrachtet. Beim Einlogen in die Infobox landen sie automatisch im Conversmode, Kanal 0 und werden mit den "Spezial"-Kommandos bombadiert. Beispiel:

P CVHOST DB0IE

akzeptiert DB0IE-0

 

P CVHOST DB0IE-15

akzeptiert DB0IE-15

 

P CVHOST "DB0ME DB0IE-15"

akzeptiert DB0IE-15 und DB0ME-0.

Parameter CONHSSID <ssid>

Normalerweise wird zum Connecten eines anderen ConversHosts (s./CONH) die SSID 0 verwendet. Manchmal kann es nun notwendig sein, ein andere SSID dafür zu verwenden, um z.B. Konflikte mit FlexnetInternode-QSOs zu vermeiden. Man setze dazu hiermit die SSID die beim Connect verwendet wird. <ssid

Diagnose+Manipulation im laufenden Betrieb

WAtch [ ADD | INS ] Call <call> [ aktion> ] [<text>]
WAtch
WAtch Del NR <nr_des_eintrag>

Mit diesen Befehlen ist es möglich eine Tabelle mit bis zu 10 Einträgen zu verwalten, die den Zugang von automatischen Stationen überwacht und kontrolliert. Dies ist notwendig, um z.B. die Laufzeitmessung eines Nachbar-Digis zu einer Mailbox zu unterbinden, falls benötigt. Dann kann man mit

WATCH ADD CALL DB0SUF SILENT

verhindern, daß dieser Digi zur Box durchkommt.

Die möglichen Aktionen sind:

 

SILENT
Ein SABM des entsprechenden CALLs wird nie beantwortet (auch nicht mit DM oder DISC)

DM
Ein SABM des entsprechenden CALLs wird immer mit DM (Busy) beantwortet.

LOG
Ein Connect des entsprechenden Calls wird in das Logbuch eingetragen.

NOEXTCONNECT
Das entsprechende Call kann zwar die Infobox des Digi connecten, aber von dort aus nicht herausconnecten

MAXCONNECT <0..255>
Das angegebene Call kann nur maximal so oft connecten.

Hinweis:

Dabei ist zu beachten, daß die Anzahl der Connects meistens nicht viel mit dem Datendurchsatz zu tuen hat. Siehe dazu auch bitte den Anhang auf Seite *.

REDIRECT <Portnr>
gleiche Funktion wie normales REDIRECT (s.Seite
*), aber halt automatisch

 

Diese Optionen lassen sich beliebig kombinieren (z.B. LOG und DM). Gibt man einen Text zu Schluss an, so wird dieser beim Connecten durch die entsprechende Station an diese ausgegeben.

 

Als Argument für CALL kann man auch den Joker ? verwenden. Beispiel D??EP oder W1????. Dabei muß die Anzahl der Zeichen aber immer genau 6 betragen.

 

Mittels WATCH alleine bekommt man ein Auflistung der Einträge.

Durch

WATCH DEL NR 1

wird der erste Eintrag (der mit der Nr.1) gelöscht; die anderen rücken dann auf.

Ändern eines Eintrags ist nicht trivial möglich; er muß dazu gelöscht und kommplett neu eingegeben werden.

PUT <id> <Text>

Schleußt den TEXT in das QSO mit der Nr <ID> ein

PARAMETER PORTCOPY <von> <nach>

gibt alles was auf Port <von> geschieht auch auf Port <nach> aus.

Achtung: Port <nach> sollte natürlich WESENTLICH schneller sein als Port <von>; ansonsten gibt es fürchterbares!!!

REDIRECT <QSONR> <AUSGABEPORT> [Ersetzt durch p <nr> Trace -IB filter]

Alle I-Frames des QSO mit <QSONR> werden 1:1 (ohne Wiederholungen - also die reine Info) auf dem Port <AUSGABEPORT> wiederholt. So kann man dann im Monitor recht gut QSOs beobachten, die z.B. nur durch den Digipeater laufen.

Derselbe Befehl mit Ausgabeport auf 0 gesetzt schaltet die Kopierei wieder aus. Die QSONR kann z.B. mit U X <call> ermittelt werden.

Es können beliebig viele QSOs umgeleitet werden. Der Ausgabeport sollte dann aber hinreichend hohe Baudrate haben.

DQueue qsonr | seg:off

<kein Sysop!> Gibt eine mBuf Struktur aus Bei qsonr<100, die von txq[0-7], bei qsonr=101, tx_root von Iface 1 bei qsonr=102, tx_root von Iface 2 bei qsonr=100, pmDelRoot bei qsonr=2xx, die von txq[0-7], des cb[qsonr-200], aber mit vollen Daten ansonsten wird der Speicherbereich gecastet

TXQu qsonr

<kein Sysop-Befehl!> Setzt alle TXQ des QSOs auf TXED ! GEFÄHRLICH !!! DEBUG ONLY

PARAMETER STOPFEN <AnAus>

Frame Stopfen, an/aus. Default AUS, da dies einige Boxen nicht vertragen wenn mehrere Zeilen in einem Frame kommen(!)

LOg [CLEAR] [L]

Logbuch ausgeben bzw. löschen.

Bei alleiniger Angabe von "LOG" wird nur die Anzahl der Einträge im Log ausgegeben, bei LOG L wird das komplette Logbuch ausgegeben.

Folgende Ereignisse werden ins Logbuch eingetragen:

* Verwendung von COMment durch den User

* PRIV und SYSOP Befehle mit Vermerk ob erfolgreich

* Manipulationsversuche durch Nicht-Sysops

* Selbstconnects von User

* Schleifen bei Converslinks

* mittels WATCH definierte Ereignisse

Alle übrigen Meldungen sind lediglich zu Fehlersuchzwecken interessant

PARAMETER TRANSLOG

Hat das Logbuch einen bestimmten Umfang erreicht, wird automatisch die Verbindung zu einer Mailbox aufgebaut, das Logbuch wird dann dort hinterlegt, und bei Erfolg in DigiWare gelöscht. Dieser Logtransfer ist z.Zt. noch nicht konfigurierbar, d.h. es wird immer versucht DL1EBQ @ DB0IZ das Logbuch zu schicken :)

PARAMETER TRANSLOG stösst den Logtransfer manuell an.

PARAMETER STAMODE 0..2

(Befehl und Funktion wurde wg. Verdacht auf groben Unfug seit 0.91d entfernt. Nunmehr spiegeln die LEDs den Kanalzustand in 1 Sek-Samples wieder.)

Bestimmt die Verwendung der Status LEDs im TNC4 (FALCon).

 

0 Sie sind immer aus.

1 Die grünen Status LEDs bilden eine 4 Bit Binär Zähler (0-15 Sek).

2 Die grünen Status LEDs zeigen binär die Anzahl der Connects an.

3 Sie zeigen an, wenn auf dem entsprechenden Kanal noch nicht gesendete Pakete in der Sende-Queue stehen (Voreinstellung)

4 Die grünen Status LEDs blinken zufällig (STAR-TREK-Effekt - man erinnert sich sicherlich noch an den Computer auf der USS Enterprise, der die Ausführungen von Mr.Spock so schön im Hintergrund visualisierte).

 

Beim Starten von DigiWare werden die LEDs eingeschaltet, und nach Erreichen der Hauptschleife (= Normaler Betriebszustand) wieder ausgeschaltet.

PARAMETER SYSOPCALL <call>

Ist das System aus Speichermangel busy, so ist es trotzdem möglich unter diesem Call (SSID ist relevant!) sich in das System einzuloggen.

P SYSOPCALL DG9EP-7

 

PARA PASSWORD <startwert> ! NUR BEIM CFG FILE !

legt das individuelle Passwort fest. <Startwert> ist eine Zahl im Bereich 1 bis 60000.

 

ACHTUNG: Wird dieser Befehl im CFG File vergessen, so ist das Passwort im Digi konstant - und jeder, der die Quelltexte kennt, kann sich als SYSOP in EUREN Digi einloggen!

 

Um die Passwort-Tabelle, mit deren Hilfe man sich als Sysop priviligieren kann zu erhalten, gibt man <Startwert> als Aufrufparameter dem beiliegendem PWGEN.EXE bei. Beispiel: PWGEN 231

s.a. PRIV (Seite *)

Der TRxC-Pin liefert als Ausgangssignal die jeweils vom Baudratengenerator gelieferte Frequenz. Dieser Parameter kann nicht benutzt werden, wenn in den TRxC-Pin ein externer Takt eingespeist werden soll.«ewenn»

Debug-Interface

DigiWare besitzt eine eigene primitive "Oberfläche" (in FD_DUMP). Sie ist SEHR unkomfortabel und undurchsichtigt. Sie muß noch dringend überarbeitet werden.

Sie ist in beiden Versionen (TNC4 (FALCon) und PC) verfügbar. Beim TNC4 (FALCon) wird sie über die V24 angesprochen. Die V24 Parameter sind davon abhängig, welche Argumente beim Aufruf von FALCLDR.EXE verwendet worden sind.

Beim PC ist sie über die normale Tastatur erreichbar. Folgende Möglichkeiten bestehen:

CTRL-N Monitorausgabe an/aus

Sollte immer aus sein, da die Ausgabe des DEbuginterface auf die v24 nicht im Interrupt läuft, und somit den Digi bremst, wenn viel reinkommt; das ist bei Monitor der Fall.

CTRL-F Sysopbildschirm

schaltet um auf den Connectbildschirm. Dort werden maximal die Daten von 10 aktuell laufenden QSOs zeilenweise ausgegeben. Es ist gleichzeitig der "Bildschirm" auf den alle Daten des eigenen QSOs landen.

CTRL-E Monitorbildschirm

CTRL-P LOOPBACK einrichten

Sollte der Befehl :K keine Wirkung zeigen, so könnte es sein daß im CFG-File kein LOOPBACK Interface eingerichtet wurde. Dies kann hiermit nachgeholt werden. Also CTRL-P betätigen und anschliessend noch einmal :K versuchen.

:K Connecten der Infobox

Benutzt man das Debuginterface zum Connecten der Infobox, so ist man zwar nicht automatisch Sysop, aber es genügt die Angabe von PRIV mit irgendeinem beliebigen Argument, um sich als Sysop auszuweisen. s.a. CTRL-P

:+n
:-n

Ein und Ausschalten der Darstellung der Frames auf iface n. Dabei ist auch die Angabe von mehren IFACEs möglich;

:-1245

s.a. (falls schon dokumentiert :-) ): ctrl-L ctrl-n ctrl-i ctrl-a

ALT-F1 .. ALT-F10
#<nr>

Analoge Befehle (dessen erste Form nur in der PC-Version vorhanden ist). Um den Ausgabebildschirm auf ein anderes QSO zu schalten.

User Sicht

Besonderheiten

IDENTS

In DigiWare gibt es Idents. Idents sind symbolische Namen unter denen der Digi anstelle des Calls connected werden kann. Idents sind aus THENET wohlbekannt. Sie bitten den Vorteil daß sie vom Sysop frei gewählt werden können (MYIDENT portnr ident), daß sie immer den gesamten SSID Berich (0 bis 15) abdecken und dadurch viele Uplink QSOs eines Users gleichzeitig möglich sind. In DL wird meist das KFZ-Zeichen des Digi-Standortes verwendet (z.B. SG bei DB0ME in Solingen). Der Nachteil ist, daß IDENTS angeblich nicht zulässig sind. Da aber nirgendwo festgelegt ist, daß jede Aussendung mit dem Lizenz-Call zu versehen ist, können m.E. durchaus IDENTS auf den genehmigten Einstiegsfrequenzen verwendet werden, sofern alle 10 Minuten eine Bake darauf hinweist, daß IDENT = CALL ist (also DB0ME = SG).

Unter DigiWare werden Idents allerdings nur auf den Usereinstiegen verwendet. Sie werden auch nicht in das Flexnet geforwardet, etc.

Labermodus

Es ist möglich vom Prompt des Digipeaters aus jedem anderen User im Digi, der die Infobox oder den Convers benutzt, eine Nachricht zukommenzulassen. Dies funktioniert wie im Convers (dort allerdings mit voran gestelltem "/") einfach durch Eingabe des Rufzeichen mit dem Text dahinter.

 

DL1EBQ Moin Thomas!

 

Ein Befehlswort wie bei BayCom oder DieBox (MSG, TALK) ist dabei nicht notwendig (aber möglich: "TALK DL8MBT Moin" oder "MSG DF3AV Grüß Gott" werden akzeptiert).

SABM und FRACK auf dem Interlink

Da Interlinks fast störungsfrei sind und es andereseits relativ lange dauern kann, bis ein via Flexnet gefundenen Digi connected ist, wird in solchen Situatione T1 adaptiv (nämlich hoch) eingestellt. Also ist T1 während des Linksetups unabhängig vom eingestellte T1's des Kanals.

Anzahl der Connect

DigiWare zählt bei jedem Connect mit der Infobox die Anzahl der Connects und den gesamten Durchsatz (in Paketen pro Minute) auf allen Verbindungen zu dem jeweiligen Rufzeichen.

MHeard Routing, TheNet(Node) und FlexNet's FIND

Bei Routing nach der MHeard Tabelle kommt es zu Problemen, wenn die gesuchte Station einen Knoten benutzt (egal ob als Einstieg oder beim Durchconnecten), der eine nicht transparente Adressierung verwendet. Dies liegt an der Verwaltung der Rufzeichen durch derartige Knoten - ihr eigenes Rufzeichen erscheint nicht im Digipeaterfeld.

In einem solchen Fall muß man halt diesen Knoten connecten, und dort in der Userliste schauen, wo die gewünschte Station einsteigt.

Ein ähnliches Problem ergibt sich bei dem FIND Befehl der RMNC/Flexnet-Digis. Der verwendete UI-Frame enthält dabei ein verdrehtes Rufzeichenfeld. Aus diesem Grunde werden derartige Frames nicht in der MHeard-Liste gespeichert.

User Befehle

Die Buchstaben die im folgenden grossgeschrieben sind, muessen mindestens eingegeben werden, damit der Befehl erkannt wird.

Bei Befehlen mit länglicher Ausgabe (USER, LINKS, etc) läßt sich die Ausgabe kürzen, indem man ein textuelles Argument mit angibt. Dieser Text muß in einem Eintrag vorhanden sein, damit er ausgegeben wird.

Aktuelles

hiermit wird der Text AKTUELLES ausgeben. Dieser Text ist für aktuelle Meldungen vorbehalten, z.B. geplante Änderungen in der nächsten Zeit, Hinweise auf neue Links usw.

Beacon

Anzeigen der Baken, die von DigiWare regelmässig ausgestrahlt werden.

 

Beispiel:

 

1. 2. 3. 4. 5. 6.

 

1. P1 1 Min. ( 1) TNC4 (FALCON) "##INFO##"

2. P1 2 Min. ( 1) TNC4 (FALCON) "##REMOTE##"

3. P1 10 Min. ( 5) TNC4 (FALCON) "DB0ME in Solingen"

 

 

1. Intern verwendete Nr. der Bake

2. Port auf dem gesendet wird

3. Sendeintervall (in Minuten)

4. Abstand bis zur nächsten Aussendung der Bake (in Minuten)

5. ZielCall (und ggf. Pfad)

6. Bakentext, der im Infofeld des UI Frames auftaucht

BOx
MAil

Kurzbefehl zum Connecten der nächsten Box.

Der Weg wird vom Syop mit den Befehlen PARAMETER BOXINTERFACE und PARAMETER BOXPATH eingegeben.

Bei einigen Terminalprogrammen, die Textmeldungen wie

"*** connected TO ..."

nur dann auswerten, wenn vorher ein Connect-Befehl gegeben wurde, werden deshalb die Verbindung zur Box nicht mitbekommen, und deren Mailboxsauggeneratoren werden evtl.dann nicht arbeiten.

CLear

Genau wie bei THEBOX kann der Benutzer seine Sendebuffer im TNC4 (FALCon) löschen. Das duerfte aber nur sehr selten notwendig sein.

COMment <Text>

Hiermit kann der Benutzer dem Digisysop einmal pro Connect einen einzeiligen Text hinterlassen. Dieser wird automatisch mit Uhrzeit, Datum und Call versehen und dem Sysop beim nächsten Login zugeleitet.

Dies ist natürlich kein Mailboxersatz, sondern nur für kurze Mitteilungen an den Sysop gedacht. Beispiel:

COMMENT Warum geht der Link nach Groenland nicht?

Connect <pfad>

Connectversuch, der Pfad dahin wird automatisch gewählt, soweit möglich.

Es sind verschieden Schreibweisen zulässig:

C db0aaa v db0aab

und

c db0aaa db0aab

sind gleichwertig. Ebenso haben

C db0aaa v db0aab,db0aac

und

CON db0aaa db0aab db0aac

sowie

C db0aaa db0aab, db0aac

den gleichen Effekt.

 

Der Digi gibt als Antwort einen Text wie z.B.

*** link setup... to DB0ONA via DB0ME-5,DB0ME-2 (Interlink - Port 2)

 

Ist bei dem Digi z.B der Port 1 der Usereinstieg und alle anderen Ports Interlinks und erhält man auf die Eingabe

"C DB0DQ"

die Antwort

*** link setup... to DB0DQ (Userport - Port 1)

so sollte man sofort die Eingabetaste drücken, um den Connectversuch abzubrechen! Der Connectversuch läuft in diesem Fall nämlich auf dem Usereinstieg des Digis, da der Router keinen Weg zum Digipeater DB0DQ gefunden hat. Und DB0DQ (Feldberg/Schwarzwald) auf dem Usereinstieg von Solingen aus zu erreichen, ist unmöglich...

CONVers <Kanalnr>

Conversmodus (Konferenz). Dieser Modus erlaubt einer großen Anzahl von Stationen eine Gesprächsrunde aufzubauen. Dabei sind bis zu 32767 verschiedene Runden gleichzeitig möglich.

Man kann vom Prompt her auch z.B. C 6666 eingeben. Da 6666 kein gueltiges Call für einen Connect darstellt, wird automatisch Convers Kanal 6666 gewählt.

 

Desweiteren unterstützt DigiWare das sog. " Vernetzte Convers (ConversD)". Dies ist vereinfacht gesagt ein Verfahren, was dafür sorgt, daß alle angeschlossen Digis sich anscheinend einen grossen Convers teilen. Jede Station im Convers eines Digis nimmt auch gleichzeitig an dem anderer Digis teil. Dies geschieht automatisch und ohne Dazutuen des Users.

 

Es gibt noch weitere Möglichkeiten mit anderen Usern in Verbindung zu treten, z.B. /INVITE, /<call> und <Call> (auf der Kommandozeile in der Infobox).

 

Innerhalb des Convers sind folgende Befehle möglich (dabei muß das / bzw. ! immer in der ersten Spalte stehen):

 

/<call> <text>

private Nachricht an <call> schicken. /Send /WRite, /TALK, /MSG geht auch. Wird <call> nirgendwo im lokalen Convers (also im Digipeater dem man selber benutzt) und auch nirgendwo in der Infobox gefunden, so wird der Text in das Conversnetz selber geschickt, so daß auch die auf anderen Digipeatern sitzenden Stationen erreicht werden können.

 

/<nr>
/ch <nr>

wechselt auf Kanal Nr. <nr>. «awenn intern=1»begibt sich ein Sysop zunächst auf Kanal 99 und wechselt dann auf irgendeinen anderen, so wird dessen logon Meldung nicht an die anderen User geschickt

 

/Help

Kurze Hilfestellung

 

/Invite <call>

<call> wird aufgefordert, sich am QSO zu beteiligen, sofern er mit dem Digi verbunden ist.

 

/User <kanal>

Liste der Benutzer. Ist <Kanal> angegeben,so werden nur diese angegeben. /Who geht auch. Dabei bedeuten:

chan

Channel=Kanalnr.

host

Rufzeichen des Digis bei dem der jeweilige User in das Convers-Netz einsteigt.

login at

Uhrzeit und Datum an dem der jeweilige User sich einlogte

tx

Anzahl der Byte die er schrieb

priv

Anzahl der Byte die er bei privaten Nachrichten schrieb.

call

ist nun das jeweilige Call. Da über das Convers-Netz z.B. auch WAMPES-Systeme zugeschaltet sein können, die etwas anderes konfiguriert sind, ist es auch möglich daß in dieser Spalte NUR ein Name und kein Call steht!

 

/LINKS

Zeigt die Digis an, mit denen man im vernetzten Convers direkt verbunden ist.

 

/BYE
/Quit

Beenden des Convers-Modus mit Rückkehr zur Infobox.

 

/DISConnect

Beenden des Convers-Modus und der Verbindung zum Digi

 

/PERSonal <Text_mit_Vorstellung>
/NICK <Text_mit_Vorstellung>

Seit 0.80: Hier kann man seine Vorstellung (Name, Standort) angeben. Die kriegt dann jeder sich einloggende angezeigt. Und in der User Liste wird es auch angezeigt.

TIP: Viel-Converser sollten sich eine kurze Vorstellung auf eine Funktionstaste legen; bei mir (ich verwende GP) z.B. ist der Inhalt von f1.gpi entsprechend:

/PERS Walter, Hochdahl, dl65b

 

/Name <vorname>

Vor 0.80: Setzten des eigenen Namens

Seit 0.80 zeigt eine Liste der von den User verwendeten Namen an. s. /PERSONAL

Beispiel:

chan. call Vorstellung

. 69 - dh1dae - .

. 69 - dg9ep - .*

. 69 - db4ut - .

.6666 - dg9ep - Walter, Hochdahl, dl65b.

.6666 - dl7gai - Hans, Konstanz (JN47OQ), Z29.

.6666 - dd4eb - .*

.6666 - dh1dae - Ulf, Siegen (JO40AV), O16.*

.6666 - dg1ehe - . (AWAY)*

 

/AWAY [<Text>]

Zeigt an, daß man nun mal nicht zu erreichen ist. Dabei wird den anderen Conversteilnehmern <TEXT> angezeigt. Die Tatsache der Abwesenheit wird weiter in die Userliste angezeigt. Nochmaliges AWAY erzeugt eine BIN WIEDER DA - Meldung.

Ist eine recht praktische Angelegenheit.

 

/LIST

Zeigt eine Liste der benutzten Kanäle (mit Überschrift etc.) an. Gibt man irgendein Argument an (z.B. /LIST *) so werden alle (auch unbenutzte) in den letzten 12 Stunden verwendete Kanäle (auch derzeit unbenutzte) angezeigt. Die Kanalüberschriften werden mit /TOPIC gesetzt

Beispiel:

chan. User/Loc. seit (bis) Thema

0 0/ 0 5.9 15:02- 5.9 15:03 #---

1 0/ 0 5.9 15:04- 5.9 15:04 #---

18 1/ 1 5.9 15:03- 5.9 15:04 #Linux und Wampes

69 3/ 3 4.9 18:57- 4.7 18:57 #Karlsruhe live

4711 0/ 0 4.9 8:36- 5.9 6:34 #Usertreff RTTY Relais DB0QF+DB0QFA

6666 5/ 5 5.7 15:06- 4.7 18:48 #Gerd Grollmaus Groller Glub

 

 

/CONnect <call>
/Xconnect <call>

Zwingt Call auf den eigenen Convers Kanal indem er vom Digi connectet wird. Andere Digis werden durch ein Q oder ein B im ZwangsCTEXT des Digis sofort wieder abgeworfen. Da es aber trotzdem immer wieder zu unerfreulichen Spielereien seitens der Looser kam ist seit der 0.78.1226 es nur noch möglich Stationen auf mit Userport gekennzeichneten Kanälen zu connecten.

 

 

/EXClude <call> <Text>
/IMSG <call> <Text>

Gegenteil von MSG. Alle ausser <CALL> kriegen den Text.

IMSG DF3VI Er hat heut' Geburtstag...

 

/TOPic <Text>

Legt eine Überschrift für den aktuell benutzten Kanal fest. Nur ein Channel-Operator kann dies ändern. (s. /CHOP)

 

/CHOP <call>

Hiermit kann ein "Channel Operator" (das ist derjenige, der zuerst einen Kanal benutzte und deshalb einige Sonderrechte hat) dieses Recht auf einen anderen User kopieren. Digi-Sysops sind immer ChannelOperator.

 

/ME <Text>
/Action <Text>

Ein echter Nonsense Befehl: Man verwende als <Text> eine Tätigkeitbeschreibung in der 3.Person z.B. /ACTION gähnt

 

/BAYCOM

Schaltet die Ausgabe der Texte auf einen anderen Modus um, der u.U. übersichtlicher ist als der Standardmodus. Nochmaliges /BAYCOM schaltet dann wieder zurück

 

!<Befehl>

<Befehl> der Infobox ausführen (z.B. !MHEARD)

 

CQ <text>

Startet ein CQ Ruf auf der Benutzerfrequenz (wie bei THENET). In <Text> kann man (aber muß man nicht) dann weiteres reinschreiben.

Beispiel:

CQ Warum hört mich denn keiner?

DIr

Eine Liste der verfügbaren Texte, die mit READ gelesen werden können wird ausgegeben. Beispiel:

*** Vorhandene Texte (lesen mit READ <name>):

Name Laenge Erstellt am Wie oft gelesen

-----------------------------------------------

INFO 802 6.3 13:38 3

AKTUELL 2033 6.3 13:37 11

 

Destination [<call> | <zeitlimit>]

Gibt den Weg (Digipfad) zu <call> aus, sofern bekannt. Beispiel:

 

DG9EP-15 de DB0ME (13:02 Local)-> d db0aim

*** route to DB0AIM: via DB0ME-11,DL0WST (Port 2) T=87

 

Nach einiger Zeit kommt dann meist die genaue Wegbeschreibung:

 

*** route: DB0ME-11 DL0WST DB0AMU DB0AIM

 

Wird Call nicht gefunden, so wird "*** no route to DB0XYZ" angezeigt.

Man kann aber auch "DEST HB9" eingeben, und bekommt so alle Schweizer Digis angezeigt. Der Phantasie sind dabei keine Grenzen gesetzt:

DEST DB0

d DK0M

D 9X

usw.

 

Eine weitere Eingabeform ist "DEST 500". Damit werden nur die Ziele ausgegeben, die sich in maximal 500*0.1 sek. erreichen lassen.

Ein Argument ist nicht zwingend. Es wird dann automatisch DEST 600 angenommen.

ECho <text>

<text> wird von DigiWare mit Uhrzeit versehen und sofort wieder zurück gesendet. Könnte z.B. zur Laufzeitmessung verwendet werden.

Help [Stichwort]
? [Stichwort]

Die wichtigsten Befehle werden aufgelistet. Mit Stichwort kann man Hilfe zu bestimmten Befehlen abrufen. Beispiel: HELP LINKS

Info

Infotext über Station und Soft- und Hardware abrufen.

Wird vom Sysop mittels des Befehls WRITE INFO erzeugt.

Links [text]
POrt [text]

Liste der bestehenden Linkverbindungen, und deren Nachbar-Digis.

Man kann auch ein selektives Argument angeben:

 

LINK DB0I

LINK BOX listet nur die Boxen

LINK --- listet nur die ausgefallenen Links.

usw.

 

Beispiel:

 

DG9EP-15 de DB0ME (13:05 Local)-> LINK

 

Call SSID Laufz. Port System Bemerkungen

----------------------------------------------------------

DB0IZ 0 P2 Box

DB0ME 0-10 P3* 19200-Baud-Einstieg

DB0IZ 9 P4 9600-Baud-Einstieg

DB0BM 0-15 23/88 via DB0ME-11 Flx Juelich

DL0WST 0-15 (---) via DB0ME-11 Flx Birk/Bonn

DB0END 0-15 17/81 via DB0ME-11 Flx Ennepetal

DB0RWI 0-15 18/82 via DB0ME-11 Flx Duesseldorf

DB0ONA 0-15 ( 897) via DB0ME-11 ThN Idarkopf

DB0QS 0-15 54 via DB0ME-11 TCP Dinslaken

 

 

CALL:
Das Call des Nachbardigis

 

SSID
Der SSID-Bereich des Nachbarn

 

LAUFZ.
Durchschnittliche Laufzeit zu diesem Digi in 1/10 Sekunden.
Zwei Werte sind die eines FlexNet-Nachbarn. 0 zeigt, daß eine Messung noch nicht stattgefunden hat, Bei ---- ist eine Verbindung nicht möglich. Ist der Wert bzw. --- in Klammern (im Beispiel DL0WST und DB0ONA) so kennt der Router bessere Strecken dorthin; die angegeben Strecken werden also nicht benutzt.

 

PORT
Weg zu diesem Digi: Port = Direkte Verbindung oder via <call>. Der Stern hinter P2 zeigt, daß man selber über diesen Port "funkt". Weiterverbinden hierüber erzeugen also eine unerwünschte Schleife, die zu der Meldung "Linkloop detected" führt. Ein Punkt hinter diesem Port zeigt an, daß z.Zt. die Laufzeitmessung stattfindet. Dies ist nur zur Information gedacht; das hat keine Auswirkungen auf die angezeigte Laufzeit oder ähnliches.

 

SYSTEM des Nachbardigis:

BOX Mailbox

ThN TheNet(Node)

Flx Flexnet (RMNC) (wird automatisch erkannt)

Bay BayCom (wird automatisch erkannt)

 

BEMERKUNGEN

Beliebiger vom Sysop eingegebener Text. Sinnvollerweise die Geographische Beschreibung o.ä.

 

MHeard [Long] <text>

Liste aller bisher gehörter Stationen.

Gibt man MHEARD LONG an (oder auch nur M L) erhält man eine ausfürliche Liste aller innerhalb der letzten 10 Minuten gehörten Stationen.

Gibt man als <text> ein Rufzeichen (oder Teile davon) an, so werden nur der Eintrag für passende Rufzeichen angezeigt (sofern vorhanden).

Diese Informationen werden auch beim Autorouten verwendet (s. CONNECT).

 

DG9EP-15 de DB0ME (13:05 Local)-> MH L

 

MHeard last 5 min:

Date/time port frames CALL (via) - proto.

------------------------------------------------

13:31-20:12 P4 492 DG1EHE - ax:491 u:2

19:20-20:12 P4 70 DL1ELA - ax:69

8.3 -20:12 P1 6845 DB0END v DB0ME-11 - ax:2575 Flex:4269 u:5

20:11-20:12 P4 2 DD8KO - ax:2 d:2 u:2

8.3 -20:12 P1 5432 DB0RWI v DB0ME-11 - ax:93 Flex:5339

8.3 -20:12 P1 643 DB0MKA v DL0WST-7 DB0ME - ax:643

8.3 -20:12 P2 45189 DB0IZ - ax:45185

8.3 -20:12 P1 7175 DL0WST v DB0ME-11 - ax:2363 Flex:4812 u:3

19:37-20:12 P4 72 DL1EET - ax:72

18:05-20:12 P1 48 DC3KM v DB0PRA-9 DB0ME-11 - ax:48 d:2 u:2

20:05-20:12 P4 15 DG9EP - ax:15

 

Im Beispiel wurde also DC3KM am heutigen Tag zwischen 18:05 und 20:12 auf Port 1 (P1) gehört. Dabei sendete er ingesamt 48 I-Pakete ab (ax:281). Weiter läßt sich schliessen daß er zweimal ein UI-Paket (warscheinlich 'ne Bake) losschickte (u:2).

Neben "normalen" AX25 I-Paketen, zählt DigiWare auch andere Protokolle: NetRom (s.o), FlexNet, IP (TCP/IP) und ARP (wird im Zusammenhang mit TCP/IP) verwendet. Alle anderen verwendeten PIDs werden unter "Son:" geführt. Eine Auflistung aller "Sonstiger" PIDs erhält man mittels MH PID. Diese Liste ist aber dann systemglobal und nicht für jedes einzelne QSO.

Als weitere Angaben werden die Anzahl der Frames, die am Digipeater vorbei (also ohne DigiCall im Pfad - Bei Duplex Digis ist dies nicht ungewöhnliches; bei Simplex Digis allerdings ein flame-würdige Untat :)) gesendet wurden als d: angezeigt.

Desweiteren gibt es noch "Dig:". Hier wird gezählt, welche Userstation wie oft von dritten als Digipeater benutzt wurde.

In den beiden ersten Spalten (mit der Bedeutung "zum ersten Mal gehört" und "zuletzt gehort") gilt generell, daß die Uhrzeit nur dann angegeben wird, wenn es sich um "heute" handelt. Ansonsten wird immer das Datum angegeben. Dies ist an dem Punkt anstelle des Doppelpunkts zu erkennen. Im obigen Beispiel wurde demnach DL0WST zuerst am 8. März (8.3) gehört (und nicht um 8 Uhr 3 Minuten).

Nodes [LONG] <Text>

Die altbekannte Liste der bekannten Digipeater, wie sie auch TheNet hat. Die angezeigten Ziele können noch nicht normal mit CONNECT erreicht werden. Dazu muss der Befehl NRC verwendet werden - siehe unten.

Gibt man als <text> ein Rufzeichen (oder Teile davon) an, so werden nur der Eintrag für passende Rufzeichen angezeigt (sofern vorhanden).

Ist die Verwendung des NetROM-Routers nicht aktiv, so erscheint stattdessen die DEST-Liste.

NRC <call>

Versucht eine Verbindung mit <Call> aufzubauen. Dies geschieht auf spezielle Art und Weise:

 

DigiWare kann anzeigen (Befehl NODES) welche Ziele ihm von NET/ROM (TheNet, TheNetNode) - Knoten her bekannt gemacht wurden (d.i. Welcher NODES-Broadcasts er empfangen hat).

Um nun in absehbarer Zeit eine weiche Schnittstelle zum Uebergang vom FlexNet in das NET/ROM Netz schaffen zu können, steht nun vorlauefig dieser Befehl zur Verfuegung. Damit kann <call> connected werden, sofern es in der NODES Liste drin steht. Einige Hinweise noch dazu:

 

1) Dies ist nur ein Experiment! Es soll sich zeigen inwieweit so etwas überhaupt gebraucht wird und auch machbar ist.

 

2) Via-Connects über DB0ME/DB0IZ zu und über NET/ROMs sind (noch) nicht möglich, es muss auf jeden Fall die InfoBox von DB0ME connected werden.

 

3) Für sichere Verbindungen ist auf jeden Fall der normale Connect-Befehl vorzuziehen - NET/ROM ist prinzipiell nicht schleifenfrei.

 

4) Die Link-Setup Meldungen sehen etwas anders aus; und es gibt mehrere davon.

Parameter [portnr]

Anzeigen der Digi-Parameter. Nicht so interessant für die Mehrzahl der Benutzer, deshalb sparen wir uns diese (etwas längliche) ausführliche Beschreibung an dieser Stelle.

 

Ein Beispiel:

HOCHDAHL 2. 3.1993, 13:30 TimeOut: 240 min.

LZMess:ON DNChk:OFF DISPFr:OFF SMOOthFr:OFF Net/ROM:ON

CVHOSts:DB0ME

 

Ident Call Typ Baud DWait TxD NRZI Clk

1. HOCH2 DG9EP 1- 1 Interlink S1 19200 45 7 1 102

2. HOCH2 DG9EP 2- 2 Interlink S2 12000 2 1 1 21

4. HOCH2 DG9EP 6- 4 Interlink S4 12000 1 1 1 21

5. HOCH2 DG9EP 6- 5 Terminal L1

6. HOCH2 DG9EP 6- 6 Userport F1 9600 20 4 0 0

 

Port t1 t2 t3 NR Ret Pacl MaxF IPo TxW RxW UIs Mod Dig PTT Map

1. 1.0 0.2 540 80 20 256 3 40 512 512 All Sim on on 1

2. 0.0 0.0 540 8 20 256 7 40 4000 4000 All Sim on on 2

4. 0.1 0.0 540 8 20 256 7 40 4000 4000 All Sim on on 4

5. 0.6 0.1 655 30 20 256 5 40 512 512 All Sim on on 1

6. 1.5 0.5 540 8 20 256 4 40 512 512 All Sim on on 6

 

HOCH2 de DG9EP-1/F25 (39:30 Local)->

 

 

Ein paar Erklärungen trotzdem:

HOCHDAHL
Name des Digipeaterstandorts, so wie er von BayCom geroutet wird.

2. 3.1993, 13:30
Aktuelles Datum und Uhrzeit

TimeOut: 240 min.
Zeitpunkt nach der eine Station disconnected wird, wenn sie keine Aktivitaet zeigte.

LZMess:ON
Laufzeitmessungen zu Linknachbarn sind angeschaltetet

DNChk:OFF
Rufzeichen die bei Connectversuchen angegeben werden, werden keiner Plausibilitätskontrolle unterzogen.

DISPFr:OFF

SMOOthFr:OFF

Net/ROM:ON

CVHOSts:DB0ME

nnn
Nr. des logischen Ports

Ident

Call

Typ
Art des Kanals. Möglich sind USERPORT, INTERLINK, TERMINAL. Ausserdem Modus des Ifaces: S=TNC4 (FALCon) SCC; F=FISS (v24-KISS mit Fehlersicherung); L=Loopback; Die Nr. dahinter bezeichnet die interne Nr. des Iface (S1-S4; F1; L1).

Baud
Geschwindigkeit des Modems

DWait
DWait auf diesem Port in 10ms-Einheiten

TxD
Txdelay auf diesem Port in 10ms-Einheiten. Ist TXD gleich 0, findet eine CTS-Steuerung statt

NRZI

Clk
Modem Parameter, sofern SCC-Kanal. Bei FISS (KISS/SMACK/FLEX-CRC) ist hier die verendete CRC-Art (0=KISS,1=SMACK,2=FLEX-CRC) und die Anzahl der wegen CRC-Fehler verworfenene Pakete auf dieser Schnittstelle Angegeben

 

Wird als Portnr eine Zahl > 0 eingegeben werden nur die entsprechenden Kanalparameter ausgegeben. Wird als Portnr 0 eingegeben werden nur die globalen Digiparameter ausgegeben.

LOCator <locator> [<locator>]
QTh <locator> [<locator>]

 

Berechnungen von Länge/Breitengrad, Neu- und Alt-Locator sowie Richtung und Entfernung zwischen zwei Standorten.

Als <locator> können Alt-, Neulocator oder Gradangaben eingegeben werden.

Wird nur ein Locator angegeben, so wird der Digistandort als 2. Locator angenommen. Beispiele:

QTH JO31LF

QTH dK66d O6,57,30/N51,13,45

Quit
Bye

Beenden des Connects mit dem Digipeater (Normales Disconnecten geht genauso gut - und schneller).

Read <textname>

Einen (vom Sysop geschriebener Text) wird ausgegeben. Eine Liste aller verfügbarer Texte erhält man mit DIR.

Beispiel:

READ LINKINFO

 

Mittel READ EEPROM kann man den Inhalt des "grossen" 8k- EEPROMs auslesen. Dieser "PseudoText" EEPROM wird in DIR nicht aufgeführt.

Näheres s.u. WRITE EEPROM

STAt [ <portnr> ]

Statistiken. Wird <portnr> nicht angegeben, so werden die Daten aller Ports angezeigt. Beispiele:

STA

STA 3

Ist man als Sysop eingeloggt, so hat die eigentliche unsinnige Angabe STAT 255 die Sonderfunktion die Statistikangaben zu löschen. Es werden dann alle Werte auf 0 gesetzt.

Es wird z.B. folgendens ausgegeben:

 

Ident Call MaxBd Baud TxNetto TxBrut. RxNetto RxBrutto

1. SG DB0ME 3878 958 52561132 86158406 29943884 59016514

2. SG DB0IZ 3829 2498 12418559 31148466 96261346 115089412

3. SG DB0ME 3415 1354 13609047 22207916 1038587 2094403

4. SG96 DB0IZ 3116 299 52475434 80475466 2940360 8287099

 

Port I RR RNR REJ Poll Ack.

1. tx: 389912 307406 610 1754 118347 389912/368359 94 %

rx: 289428 303373 13131 1732 28325

2. tx: 133618 584411 34755 233 20075 133618/131300 98 %

rx: 528653 220077 0 1225 93221

3. tx: 102213 26144 57 297 17628 102213/77207 75 %

rx: 12736 36650 133 4142 3541

4. tx: 361161 165778 1148 5341 119912 361161/271817 75 %

rx: 57218 133586 707 9532 29460

 

MaxBd
Maximale Baudrate, die eff. erreicht wurde (hier ist z.Zt. noch ein Fehler drin, der manchmal unsinnig hohe Werte hervorruft).

 

Baud
Durchschnittliche Baudrate der letzten 16 Sekunden, die erreicht wurde. Es ist nicht die Bruttorate von meist 1200 Baud gemeint, sondern die wirklich an *Nutzdaten* übertragenen Zeichen.

 

TxNetto
Soviel Bytes hat TNC4 (FALCon) auf diesem Port an reinen Nutzdaten ausgegeben (ohne Wiederholungen, Header usw.).

 

TxBrut.
Soviel Bytes hat TNC4 (FALCon) auf diesem Port ausgegeben (incl. Wiederholungen, Flags, Address- und Kontrollfeldern und -frames).

 

RxNetto
Soviel Bytes hat TNC4 (FALCon) auf diesem Port an reinen Nutzdaten empfangen (ohne Wiederholungen, Header usw.).

 

RxBrutto
Soviel Bytes hat TNC4 (FALCon) auf diesem Port empfangen (incl. Wiederholungen, Flags, Address- und Kontrollfeldern und -frames).

 

Auch die Anzahl der I,RR,RNR und REJ Pakete wird getrennt nach Ports ausgegeben. Zusätzlich werden noch alle Polls gezählt.

Tech

Diagnosefunktion. Für den Benutzer meist uninteressant, aber die FALCner können dem TNC4 (FALCon) damit unters Gefieder schauen. Diese Informationen werden auch regelmässig als Bake abgestrahlt, so daß man auch im nicht verbundenen Zustand weiss, was den TNC4 (FALCon) so alles bewegt. Beispiel:

 

DigiWare 0.79.0306 SG:DB0ME

3.13:09" nRst:0 nErr:0 0:0 RTE0 at 0000:0000 SWD:0

semaMem:0 Mem:118952 Max:109688 MinMax:99560 Gaps:43

RpS:6628/1189/1189 RAck:270 ChBsy:1161 AXCB:47/47/49

mF:30/39 nNB:0 IntTbl:1 StdBy:1

 

AStCnt:8 ULSeg:4000 EPROM:CCDC

maxLen:261632 RAM:04/04 ER+

 

Die wichtigsten Werte mal kurz erklärt (eigentlich unmöglich, da sich der Inhalt ständig ändert):

 

Up:
Soviele Tage.Stunden:Minuten fliegt er schon (erst?) ohne Unterbrechung.

nRst
So oft ist er gestartet...

nErr
...und wieder abgestuerzt :)

Mem
Anzahl der Byte freien Speichers, die darauf warten von den Benutzern verbraucht zu werden (die verbrauchten Bytes werden natuerlich wieder recyclet, auch wenn kein grüner Punkt drauf ist...)

Gaps
Anzahl der ungenutzen Löcher im Heap.

RpS
Rounds per Second. So oft pro Sekunde läuft er durch die Hauptschleife (Gemittelt über die letzten 16 Sekunden). Kriterium für die Belastung. Der 2. Wert ist der niedrigste der in der letzten Stunde, der 3. Wert der niedrigste der je gemessen wurde. s.a. PARA RPS

StdBy
Dies ist ein Flag, das anzeigt, ob der letzte Reset des TNC4 (FALCon) durch Ausfall der Stromversorgung verursacht wurde. Ist dies der Fall, so wird der Wert 0 angezeigt.

Users [Long | XLong | Stat | Conv | Path ] [<Text>]

Ausgabe der Liste der im System geführten QSOs.

Es gibt insgesamt fünf verschieden Arten von Userlisten. Sie werden durch die o.g. unterschiedlichen Parameter aufgerufen.

- Bei LONG werden zusätzlich die Pfade mit ausgegeben.

- Bei XLONG kommt eine ausführliche Liste alle QSOs inkl. QSO-Statistik zustande. Hier werden allerdings keine Pfade mehr angezeigt, sondern nur die QSO Nr.

- Mit STAT wird ein Liste wie XLONG abgerufen, allerdings ist die Statistik pro QSO hier NOCH umfangreicher.

- Bei PATH kommt eine Liste aller QSOs mit kompletten Pfaden (Digipeaterlisten).

 

Mit <Text> kann bei allen Liste eine einschränkende Selektion vorgenommen werden. Ist <Text> eine Zahl zwischen 1 und 8 so werden alle User ausgegeben, die diesen Port benutzen. Diese Features wird all diejenigen freuen, die eine RMNC-User-Liste für übersichtlich halten :-). Ansonsten wird ein Eintrag nur aus gegeben, wenn er den entsprechenden Text enthält.

 

Die Normale Liste "USER"

Das links stehnde Rufzeichen hat die Verbindung aufgebaut. Rufzeichen die über einen Benutzereinstig kommen sind klein, alle anderen gross geschrieben.

Die Reihenfolge: QSOs mit dem Digi, den Ports und zum Schluss Convers-Runden. Die Gleichheitszeichen zeigen an, das es auf dieser Verbindung keine unbestätigten Pakete gibt.

Von dem jeweils links stehenden Partner ist die Verbindung initiert worde.

Beispiel:

 

=> US

->User-List<-

dg9ep-15 => CQ DF4VP => Digi dg1egl <.> dg1ehg

DB4EU <=> DL0WST DB4VQ -> conv.6666 df3ka => conv.6666

 

=> U L DG1

 

->User-List<-

dg9ep-15 => CQ

dg1egl <.> dg1ehg (1:v.db0me)

DB4VQ -> conv.6666

df3ka => conv.6666

 

=> USER LONG

 

->User-List<-

DF4VP => Digi

dg9ep-15 => CQ

dg1egl <.> dg1ehg (1:db0me)

DB4EU <=> DL0WST (1:.db0me-6,db0me-5,db0me-3)

DB4VQ -> conv.6666

df3ka => conv.6666

 

Hier befindet sich also

- DB4EU im QSO mit DL0WST. Der Weg nach DL0WST geht also über DB0ME-6, DB0ME-5 und DB0ME-3

- DF3KA benutzt gerade den Conversmodus des TNC4 (FALCon) auf Kanal Nr. 6666

- DG9EP ruft grade CQ auf der Einstiegsfrequenz (s.o)

- DL1EGL versucht gerade eine Verbindung zu DG1EHG aufzubauen (erkennbar an <.> statt <=>

- DF4VP ist mit der Infobox des TNC4 (FALCon) verbunden

- und auch DB4VQ benutzt den Convers Kanal 6666, hat aber noch nicht alle Pakete bestätigt, die der TNC4 (FALCon) ihm schickte. Das sieht man an -> statt =>

 

Durch die Möglichkeit textuelle Filter anzugeben ergeben sich sozusagen automatisch folgende Features:

 

U DIGI Alle User die mit der Infobox des Digis verbunden sind.

U conv Alle lokalen User, die im Convers sind

U cv-Link Alle Hosts des vernetzen Convers

u -> Alle QSO mit unbestätigten Paketen

 

Die Liste mit PfadeN "USER PATH"

Um die exakten, im QSO verwendeten Pfade zu erfahren, gebe man diesen Befehl:

 

1. 11:12 P1/3 I DB0ME>DL1EAM-15,db0me-13*,db0me-11,db0bm-5

2. 12:49 P4/4 I SG96>DC5KC

3. 8:08 P1/3 I DJ7CO>DB0QS,db0iz-9*,db0me*,db0me-13*,db0me-11,db0me-12

4. 8:08 P4/4 U1 DB0QS>DJ7CO,db0me-12*,db0iz-9*

5. 10:37 P1/3 I DB0ME>DG1EFV,db0me-13*,db0me-11,db0gos

6. 13:52 P4/4 I DB0IZ-9>DG1KWA-3

7. 13:36 P2/4 I DB0IZ-9>DB0IZ-5

 

 

Die Statistik Liste "USER X"

 

Nr. RxRR RxREJ RxI RxPo TxPo FrAck MaxF Paclen

-------------------------------------------------------------

1. 11:12 P1 I 134 0 10 2 108 1.0 5 256 DB0ME>DL1EAM-15 (3)

2. 12:49 P4 U7 499 40 50 22 414 16.0 7 256 SG96>DC5KC (0)

3. 8:08 P1 I 575 0 608 4 119 17.4 5 256 DJ7CO>DB0QS (5)

4. 8:08 P4 I 831 69 593 287 1391 1.4 7 256 DB0QS>DJ7CO (2)

5. 10:37 P1 I 0 0 0 2 128 - 5 256 DB0ME>DG1EFV (3)

6. 13:52 P4 I 20 1 8 4 10 - 7 256 DB0IZ-9>DG1KWA-3 (0)

7. 13:36 P2 I 67 0 188 15 0 3.0 4 256 DB0IZ-9>DB0IZ-5 (0)

 

Eine Zeile entspricht einem QSO, das mit oder über den Digipeater läuft.

Ausgegeben wird die QSO-Nr. (zur Verwendung bei KILL etc), Login-Zeit, die logische Port Nr., der Status des QSOs (ähnlich wie bei FlexNet), sowie statistische Angaben.

 

Die MEGA-Statistik Liste "USER S"

 

Diese Liste weist eine enge Verwandschaft zur "User X" Liste auf.

Einem QSO sind hier zwei Zeilen zugeordnet. In der ersten Zeile werden die Statistik über den Empfang, dadrunter diejenigen über die Aussendungen (jeweils vom Digi aus gesehen).

 

Convers-LIste "USER CONV"

 

Bei USER CONV (oder U C) erscheint die Liste der im Convers befindlichen Stationen; auch die Stationen, die über das vernetzte Convers herein kommen werden angezeigt.

Version

Gibt die Copyright-Notiz, Versionsnummer und -datum aus.

Die Quelltexte

Sofern Sie die Quelltext von DigiWare haben, können Sie mittels TURBO-PASCAL 6.0 (den gibt es z.Zt. als "NixWieWegDamitWare" SEHR billig...) oder Borland Pascal 7.0 selber Änderungen an DigiWare vornehmen. Und nur mit DIESEN Compiler in DIESEN Versionen sind Sie in der Lage EPROM- und Uploadfähigen Code herzustellen. Unter Borland Pascal 7.0 ProtectedMode ist compilieren und ablaufenlassen des Codes auf dem PC zwar möglich; die Verwendung auf dem TNC4 (FALCon) ist aber damit nicht möglich. Doch dazu als allererstes mal eine Warnung:

 

Ändern Sie die Sourcen nur dann, wenn sie die Funktionsweise von DigiWare verstanden haben! Und zwar nicht nur die von der Stelle, wo Sie was ändern wollen, sondern die Funktionsweise der GESAMTEN Software!

 

Wenn Sie Änderungen vornehmen, so MÜSSEN Sie dies in der Versionsnummer kenntlich machen (also aus 0.80b ein 0.80b.DH4CKR machen)

 

Ich werde ganz bestimmt keine Fehlermeldungen bearbeiten, die aus der Missachtung der (an sich selbstverständlichen) obigen Regel resultieren.

Es versteht sich von selber, daß nur Leute mit ausreichender Programmiererfahrung Änderungen vornehmen. Deshalb werde ich in der folgenden Beschreibung davon ausgehen, daß der Leser ausreichende Erfahrung mit systemnäherer Programmierung sowie des AX25-Protokolls hat, und bei Erwähnung von Begriffen wie DMA, SCC usw. weiss was gemeint ist.

Werden sinnvolle Änderungen am Programm gemacht, so bitte ich darum, mich davon in Kenntnis zu setzen (kurze Mitteilung á la "Ich hab NET/ROM eingebaut"), damit ich die Version nachpflegen kann.

Das gleiche gilt sinngemäß auch für diesen Text.

Lizenz, Rechtslage, Verwendung in eigenen Projekten

Desweiteren muß die im Anhang aufgeführten und auch in Dateiform vorhandene "Allgemeine Lizenz für Amateurfunk Software" (ALAS) beachtet werden.

Die Startmeldung des Programms auf der Standardausgabe und der Inhalt des Versionsbefehl darf in seinem Wesensgehalt nicht verändert werden und MUSS immer mindestens den Text

DIGIWARE (c) DG9EP

enthalten.

Die Connectmeldung bei Verbindungen via Packet Radio (o.ä) mit der Infobox (oder gleichwertigen) muß ebenso immer das Wort "DigiWare" bzw "TermWare" enthalten.

Generelles

DigiWare kann in zwei Versionen compiliert werden. Dies wird über einen Compilerschalter in der Datei FD_INCL.PAS gesteuert.

Ist der Schalter SCC definiert {$DEFINE SCC}, so wird DigiWare für den TNC4 (FALCon) compiliert, ansonsten als PC-Version.

Die PC-Version ist nur als Entwicklungs- und Testumgebung sinnvoll einsetzbar, da sie sich auf KISS/SMACK - TNCs abstützt. Bei Verfügbarkeit von entsprechenden Treiber (s.u.) ist es dann aber auch möglich DigiWare auf anderer Hardware sinnvoll einzusetzen.

 

Bei der Übersetzung in der IDE treten einige Schwächen des verwendeten Compiler zu Tage. So muß bei einer Neu-Übersetzung aufgrund von Änderungen in FD_DEF oder FD_INCL zunächst FD_INFO übersetzt werden. Je nach freiem Speicher kann es sogar sein daß es Fehler der Art "Too many nested Files" gibt. In diesem Falle die Files in denen der Fehler auftrat übersetzen (F9). Dies tritt meistens in FD_TEXT und FD_ERROR (Nomen est Omen :-) ) auf. Andere Kombinationen sind FD_DIV, danach FD_LOG und dann FD compilieren.Hilft dies nichts, so sollte man sich zunächst vergewissern, daß im Menü COMPILE der Eintrag PRIMARY FILE leer ist. Hat man danach immer noch keinen Erfolg, so sollte man den Speicherverbrauch der IDE hearabsetzen, wie im Handdbuch empfohlen. Also Linkbuffer auf DISK (sowieso), SYSTEM.TPL nicht beim Programmstart laden, und wenn all das nicht hilft LOCAL SYMBOLS off und allzuletzt INTEGRATED DEBUGGING off. Dann kann man allerd ngs auch gleich von der Kommandozeile aus compilieren. Rein prinzipbedingt treten diese Fehler meist auch auf der Kommandozeile aus. Auch MAKE hilft leider nicht weiter, er kommt mit dem TPC internen Make in die Quere.

Hinweis: In Borland Pascal 7.0 (BP.EXE) tritt das Problem bislang nicht auf.

Es gibt einen INCLUDE File mit allen möglichen Compilerschaltern.

SCC sollte nicht definiert werdenn - das ist für den TNC4 (FALCon) vorbehalten.

Beim ersten mal oder wenn FD_DEF (glocbale Definitionen) geändert wurde kann man in der TurboPascal 6.0 Entwicklungsumgebung nicht compilieren. Man nehme stattdessen PC.BAT (die setzt wiederum PC6.BAT voraus, mit der TPC.EXE aufgerufen wird). Die ASM-Dateine brauchst man auch nur für den TNC4 (FALCon).

 

Auf einem PC mit zwei Monitoren (VGA/EGA/CGA sowie einem Hercules) werden beide Monitore genutzt. Auf einem erscheinen die Ausgaben des Monitors, auf dem anderen die des Eigabebildschirm.

Bedingte Kompilierung

In DigiWare werden folgende Symbole verwendet, die in der Datei FD_INCL.PAS (und nur da!) definiert bzw nicht definiert werden.

SCC
TNC4 (FALCon) Version (Nicht PC)

ALLFAR
Alle Prozeduren sind FAR. Wg. Speichern des Stacks.

DISPLAY
LCD Anzeige am TNC4 (FALCon) angeschlossen.

USERWARE

HOSTMODE

 

Darüber hinaus gibt es noch einige Symbole, die nur innerhalb eines Moduls Bedeutung haben.

Hardware Treiber

DigiWare besitzt ein Treiberkonzept, daß es ihm gestattet fast beliebige Level 1 (also Hardware Treiber) einzubinden. Das Anbinden des entsprechenden CODES muß zur Übersetzungszeitpunkt erfolgen (also NICHT wie bei DLLs oder DDLs), der Aufruf der entsprechenden Treiber (also Starten, Initialisieren und DigiWare zur Verfügung stellen) geschieht aber zur Laufzeit des Programs.

Z.Zt. gibt es Treiber für die SCC-Bausteine und die V24 (SMACK und FLEX-CRC) des TNC4 (FALCon), sowie einen Loopback-Treiber (interne Schleife) für die TNC4 (FALCon) Version, sowie KISS, SMACK und Loopback Treiber für die PC-Version. Weitere Treiber (FTP-Packet, IPX, SCC-Karten, TNN-KISS) sind bereits angedacht, und werden evtl. mal erstellt.

Inhalt Quellarchiv

Die eigentlichen Sourcen:

FD.PAS Hauptprogramm mit Compilerschaltern

FD_INCL.PAS Enthält die Compilerdirektiven

FD_DEF.PAS Alle globale Varaiblen

FD_MAIN.PAS Hauptschleife

 

FD_AR.PAS Autorouter

FD_AXCB.PAS Verwaltung der AX25-Controll Blocks (Erzeugen, löschen, zählen)

FD_BEACO.PAS Baken, FIND-Befehl

FD_CIRC.PAS Durchgeschaltete Verbindungen

FD_CONV.PAS Convers, incl. conversD

FD_DIV.PAS enthält diverse Unterroutinen allgemeiner Art (nicht DigiWare spezifisch)

FD_DUMP.PAS Debug Routinen, Monitor

FD_ERROR.PAS Fehleraufzeichnung und Behandlung

FD_FLEX.PAS Flexnetrouter

FD_INFO.PAS Befehle der InfoBox

FD_LINK.PAS LINK-Befehl, Laufzeitmessungen Nicht-Flexnet-Digis

FD_LOG.PAS Logbuch Verwaltung

FD_MEM.PAS Gesamte DigiWareSpeicherverwaltung

FD_MH.PAS Verwaltet die MHeard-Liste

FD_NETRO.PAS Verwaltet Broadcasts von NETROM Nachbarn

FD_PROM Ansteuerung EEPROM

FD_QTH.PAS Für Befehl QTH (Autor dl7gai)

FD_STATE.PAS AX25-Status"tabelle"

FD_SUBR.PAS DigiWare spezifische Unterprogramme

FD_SYSOP.PAS Sysopfunktionen

FD_TEXT.PAS Texte der Infobox (READ, WRITE, DIR....)

FD_TIMER.PAS Zeitgeber-Verwaltung

FD_TX.PAS Erzeugt die eigentlichen Pakete

 

Nur TNC4 (FALCon) Version:

FD_V2524.PAS KISS Ansteuerung V24-2

FD_SCC.PAS Ansteuerung SCC 1-4

FD_TNC.PAS Ersatz für FD_CRT.PAS

 

FD_TNC.OBJ Zum Compilieren benötigte OBJ Dateien

FD_SDLC.OBJ

FD_PATCH.OBJ

V25IO.OBJ

 

Nur PC-Version:

FD_PCSIO.PAS KISS/SMACK Ansteuerung (vormals FDT_SIO)

FD_CRT.PAS Ersatz der CRT-Unit

FD_OVL.PAS Overlay Verwaltung auf dem PC

 

Sonstiges:

LIZENZ.DOC Lizenzabkommen zur Nutzung DigiWare

BIN25.BAT Beispiel Batch EPROM erzeugen

DEMO.CFG Beispiel Konfiguration

DIGIWARE.CFG dto.

PARCOMP.EXE Parameter Compiler

PARCOMP.PAS Parameter Compiler

PWGEN.EXE Erzeugt Passworttabelle

PW1.TXT Beispiel Passworttabelle

TABEXP.EXE Utility, expandiert etwaige in Quelltexten vorhandene Tabulatoren nach PC - Standard (Filter Funktion). Aufrufbeispiel:
TABEXP <MITTAB.DOC >OHNETAB.DOC

Funktionsweisen

Allgemein

DigiWare sollte NICHT auf KISS eingesetzt werden, da KISS die Vorteile von DigiWare nicht nutzen kann und die Frequenzen belastet.

 

Die V24-Rx-Routine (interrupt gesteuert) dekodiert die KISS-Frames und legt sie in einer verketteten Liste ab. Die Hauptschleife (im Vordergrund) nimmt sich diese Pakete einzeln und untersucht sie, ob sie an oder über MYCALL (steht in T_IFACE) gerichtet sind. Wenn ja wird nachgeschaut ob das QSO in der QSO-Tabelle steht (CB[]^). Wenn nicht wird FD_STATE.UNKNOWNQSO aufgerufen, der dann ggfs. das QSO akzeptiert. Steht es in der QSO-Tabelle übernimmt FD_STATE.CALCSTATE die Kontrolle und entscheidet was gemacht wird.

 

TX-Pakete kommen in ein TX-Queue, die dann (auch im Hintergrund) an den KISS-TNC geht.

 

Bestimmte Ereignisse (Es sind Nutzdaten eingfetroffen, Verbindung wurde getrennt usw.) werden an einen MSG-Handler weitergeleitet, der pro QSO unterschiedlich sein kann. Das ist nix anderes als eine Prozedur die über einen Pointer aufgerufen wird. Diese Prozeduren muessen "schnell" wieder zurückkehren - also keine Sortiereien über 1000 Elemente durchführen oder so. Beispiel: Die Unit FD_CONV (Convers Modus) - da dürfte klarwerden was ich meine.

Das ganze ist also ein bischen wie WINDOOFS aufgebaut.

 

Timer sind auch recht trivial - wenn sie abgelaufen sind, rufen sie eine zugehörige Routine auf. Beachte aber, daß diese Timer einen Zeiger auf ein Freigabeflag haben. Damit kann der Timer bei Bedarf angehalten werden. So stoppen wir z.B. die FRACK-TIMER wenn DigiWare sendet oder der Kanal sonst belegt ist (DCD).

 

T_mBuf ist die hauefigste Datenstruktur. Darin werden Pakete gespeichert als auch begleitende Angaben. Sie ist recht gross - wir werden später optimieren (Variante Records & so)

Timerflagfreigabe

jeder Timer hat einen Zeiger auf ein Freigabeflag. Dieses FLAG sollte normaler Weise auf einer KONSTANTE FOR_EVER_TRUE stehen.

 

Bei einem T1-Zeiger zeigt der FreigabeFlag-Zeiger zunächst auf ein mit diesem Timer assoziertes PM^ (genauer gesagt auf ein Flag innerhalb dieser Struktur). Solange dieses Paket noch nicht gesendet wurde, steht es auf FALSE. Sobald es gesendet wurde, wird es auf TRUE gesetzt. Dadurch wird verhindert, daß ein Paket zweimal in der Sendequeue steht.

Gleichzeitigt mit der Sendung, wird der FreigabeFlag-Zeiger des Timers auf eine Variable gesetzt (WICHTIG: der Zeiger wird versetzt und nicht etwa der Wert, auf den der Zeiger zeigt!), die aus einer ODER Verbindung von DCD und PTT hervorgeht, und die genau dann TRUE ist, wenn kein Träger auf der RX-Frequenz ist UND die PTT nicht getastet ist. Dadurch lauft T1 nur wenn der Kanal auch wirklich frei ist.

Probleme

Interupts verbieten

Bei Zugriffen auf gewisse Strukturen muß immer der Interupt gesperrt werden, damit im Hintergrund laufende Routinen, die diese Strukturen ändern / lesen, keine falschen Werte verursachen / lesen. Dies sind u.a.

TIMER.pbEnabled

mBuf.Txed

mBuf.ptTimer

RootRxFree

u.a.

Dabei müßen die Makros _DI und _EI benutzt werden. Der Einsatz muß paarweise erfolgen.

Umprogrammierung PC-Timer (8253)

DigiWare programmiert zwar den im PC verwendeten Timer um (von 54,8 ms auf 10 ms), bei ordnungsgemäßen Programmende (ALT-X) wird er aber wieder zurückprogrammiert. Während DigiWare auf dem PC läuft, wird die Uhr auch korrekt angesprochen.

Probleme gibt es jedoch falls der Debugger das Programm unterbricht (Breakpoint hit). Dann wird der Timer nicht zurück auf 54,8 ms gestellt; die Interuptroutine wird aber u.U. restauriert. Dadurch geht die Uhr des Rechners evtl. 5 mal zu schnell!. Das ist zwar unschön, aber nicht weiter schlimm, solange man weiter programmiert.

Verläßt man allerdings die IDE, so sollte man das (hoffentlich) beiliegende Programm NORMTIME.EXE aufrufen, daß die Uhr wieder normal schnell ticken läßt. Die Uhrzeit muß man dann auch wieder zurückstellen. Doch dabei kann es zu Problemen kommen, da dann einige Dateien auf einmal eine Zeitmarkierung aufweisen, die in der Zukunft liegt. Das kollidiert dann in erheblichem Maße mit der TP-eigenen Projektverwaltung! In einem solchen Falle am besten die betroffenen Datein mit TOUCH behandeln. In der Praxis kommt dieser Fall allerdings erstaunlich selten vor....

Verwendete Resourcen des V25+

Timer Unit

Zur Generierung des 10ms Takts und für eine Watchdog verwendet

V24

V24-0 wird als TerminalStandardausgabe verwendet; v24-1 gibt KISS/SMACK aus, falls Treiber gestartet.

I/O Ports

Einige Ports sind fest für interne Aufgaben reserviert andere sind frei verfügbar. Dazu gehört auch Port T

Nicht verwendbar sind:

P00

Port 0

EEPROM Datenbit

P01

Port 0

EEPROM Clk-Bit

P14

Port 1

Clock Interupt

P17

Port 1

READY

P24

Port 2

Watchdog-Trigger

 

Verwendbar sind:

Port T (Befehl P AD n)

Port 3-7

DMA-Kanäle

werden nicht verwendet. Nur der SCC verwendet (seine eigenen) DMA-Kanäle.

Macroservices

Für V24-Kiss Mode.

Registerbänke

Für V24-Kiss Mode.

Standby

Das Standby-Flag wird ausgewertet. Damit ist sicher erkennbar, ob ein Stromausfall vorlag.

Sonstiges

Im folgenden findet sich nun alles, was sich sonst nicht unter anderen Punkt hat einordnen lassen.

Häufige Fehler

Stichwortartig nun die Fehler die am häufigsten gemacht werden.

 

- Nicht der richtige EPROM Typ eingestellt - JP3 steht nicht in der Position für 256kByte-Eproms.

- EPROM zu langsam - der Loader muß in diesem Fall mit dem Argument -w 1 (1 Waitstate) aufgerufen werden.

- MYCALL/MYIDENT nicht gesetzt (für jeden Port notwendig)

- Im CFG-File wurde das END (Grossgeschrieben, in einer eigenen Zeile) als Endekennzeichen vergessen.

- Handbuch wurde nicht gelesen :)

Anschluss von ...

DieBox

Eine Mailbox läßt sich z.B. mittels eines am PC angeschlossenen TF-TNC an einem der Funkports vom TNC4 (FALCon) anschliessen - sehr umständlich.

Es lässt sich auch über den KISS/SMACK-Mode (s. P KISS) über die V24 des TNC4 (FALCon) zur V24 des PCs, wo DIEBOX dann mit TFPCR o.ä. läuft, machen. Dies ist aber zu einem unsicher, da KISS nicht fehlergesichert ist, zum anderen wird der Boxrechner mit der zusätzlichen Abarbeitung des AX25-Protokolls belästigt, was die Geschwindigkeit sicher nicht positiv beeinflußt.

Man kann die Box auch im Hostmode an einen der beiden V24-Ports des TNC4 (FALCon) anknuepfen (sofern das in DigiWare eincompiliert ist.

Im Endausbau wird der PC an den TNC4 (FALCon) über die SCSI-Schnittstelle parallel angeschlossen.

DX-Cluster

Mir liegen zur Zeit keine Informationen vor, welche Hard/Software Konfiguration ein DX-Cluster benötigt. Daher können wir hier auch keine Tips zu dessen Anschluss geben.

BayCom(-BOX)

Hier gilt sinngemäss das gleiche wie für DieBox. Der Anschluss kann dabei über eine BayCom-(U)SCC-Karte an den TNC4 (FALCon) erfolgen.

Die Verwendung des BayComs Kissports ist ebenso möglich, allerdings ist z.Zt. auf BayCom-Seite keine CRC-Sicherungs-Methode eingebaut. Der Anschluss der BayCom Nodes/Box an die V24 des TNC4 (FALCon) ist eine relativ elegante Lösung, es muß sich aber noch im Dauerbetrieb zeigen, ob dass richtig gut geht.

PC-Flexnet

Kein Problem.

Befehlsvergleich

DigiWare

FlexNet

TheNet(Node)

Bedeutung

B

B

B

Baken aufrufen

C <call>

C <call>

C <call>

Verbindungsaufbau

C

Conv

Conv

Conversmodus

Dest

Dest

-

Zieleliste Flexnet

Nodes

-

Nodes

Zieleliste NETROM

P <unterpara>

Mo <unterpara>

(diverse)

Digi konfigurieren

P <unterpara>

P

 

Konfiguration anzeigen

P CVHost

-

CVS

Mögliche ConversD-Partner anzeigen

U <Portnr>

U <portnr>

U

Benutzer des Kanals

U Digi

U i

 

Benutzer der Infobox

Tabelle 1 - Befehlsvergleich

Glossar

DigiWare

Digipeater Software. Abkürzung DW. Dies ist das Programm, was hier beschreiben wird... :-)

DW

s. DigiWare

EEPROM

Electrical Erasable Programable Read Only Memory. Ein Chip der im Gegensatz zum EPROM (nur ein E!) zum Löschen und Programmieren nicht aus der Platine entfernt werden muß und weder Brenner noch UV-Lampe dafür benötigt. Dafür Kapazität sehr gering. Im TNC4 (FALCon) 128 Byte. Dort werden normalerweise Parameter zwischengespeichert.

EPROM

Erasable Programable Read Only Memory. Ein Chip der mit einem externen Gerät ("Eprommer, Brenner") immer wieder neu programmiert werden kann. Behält seinen Inhalt auch nach monatelnagen Stromausfällen. Kann nur durch längere Bestrahlung mit harter UV-Strahlung gelöscht werden. Nur im gelöshchten Zustand kann ein EPROM wieder neu gebrannt werden.

Der EPROM im TNC4 (FALCon) enthält DigiWare in binärer Form.

Nicht zu verwechslen mit EEPROM

Flag

Ein Flag ist ein Kennzeichen, das bestimmte Zustände signalisiert, Der Name Flag (dt. "Flagge") leitet sich von den in den USA üblichen Briefkästen ab. Diese haben i.d.R. eine beweglichen Hebel aus Holz oder Plaste in Form einer Fahne, der vom Briefträger hochgeklappt wird, wenn er Post reingelegt hat. So kann von einem u.U. weit von der Strasse + Briefkasten entfernt befindlichen Haus einfach erkannt werden, ob Post da ist oder nicht (und sich so unnötige Wege sparen).

FlexNet-QSO

Infobox

Die Infobox von DigiWare ist die Befehlsoberfläche, die ein User sichtet, wenn er sich mit PID $F0 direkt mit dem Digi connected.

Laufzeitmessung

TermWare

Die Version von DigiWare mit Hostmode; aber ohne Laufzeeitmessung etc.

Treiber

Ein Programmteil innerhalb von DigiWare, der die hardwarespezifischen Dinge der verschiedenen Interfaces (SCC,V24-KIFF,SCSI,Loopback etc.) erledigt. Dabei ist nicht nur die Hardware sondern auch das verwendete Protokoll relevant. Wollte man auf den TNC4 (FALCon) Ports also Asyncron arbeiten so wäre ein eigener Treiber notwendig.

Upload

Das Versogen des TNC4 (FALCon) mit einer neuen Software (-Version) per PR im laufenden Betrieb.

Autoren & Unterstützer

Die Treiber für TNC4 (FALCon)-SCC und PC-KISS, die Routinen für die EEPROM-Ansteurung, der Lader für die Software sowie Design, Idee, Entwurf, Prototypen, Platine und miserable Vermarktung des TNC4 (FALCon) stammen von DG3DBI.

 

Ohne Thomas, DL1EBQ wäre das ganze Projekt TNC4 (FALCon) und DigiWare nicht möglich gewesen.

 

Irgendwie hat es Arno, DG2EAT/DL6EE trotz aller unserer Bemühungen es immer wieder geschafft die Box DB0IZ am laufen zu halten.

 

Die FLEX-CRC-KISS und conversD Routinen enstanden mit entscheidener Hilfe von Fred, DC6IQ. Von ihm stammen auch viele Tips zum Flexnet-Router.

 

FD_QTH und die DCF-Ansteuerung sowie der HOSTMODE stammen von Hans,DL7GAI.

 

Ideen und Codeteile wurden von Martin, DG6MAY beigesteuert.

 

Die Routinen für Generierung der Passwort-File und das Verfahren hierfür, sowie die Idee zu NRC und NODES stammen von NORD><LINK.

 

Alles andere, wie z.B. dieser Schrieb entstammt der Feder/Tastatur von DG9EP.

 

Auch ADACOM e.V., dem GGGG, dem Karlsruher Klüngel; Robert, DB1JJ; Werner, DD9JN; Pät, DF3VI; Henning, DF9IC; Johannes, DG3RBU; Ulf, DH1DAE; Eggi, DJ5JQ; Sabine, DL1DBC; Hartmut, DL1YDD; DL4JY; Jan, DL5UE; Flori, DL8MBT; Tommy, DL9SAU sei für ihre athletische, dokumentarische, geistige, moralische, lukullische oder bachiatische Unterstützung gedankt.

Viele Leute haben Vorschläge für die Gestaltung der Oberfläche und das sonstige Verhalten gemacht. Danke.

Und nicht zuletzt haben die User von DB0ME und DB0IZ viele Seltsamkeiten und Eigenheiten der Software im Testbetrieb über sich ergehen lassen (müssen).

Adresse

Kontaktaddresse für Fragen zu DigiWare und TermWare

Walter Koch

Feldstr. 11

40699 Erkrath

(für Hasser der neuen PLZ: 5605 Hochdahl)

 

DG9EP @ DB0IZ

koch@hsp.de

http://ourworld.compuserve.com/homepages/WalterKoch

 

Kontaktaddresse für Fragen zum TNC4 (FALCon)

Werner Cornelius

In den Siepen 17

Bochum

DG3DBI @ DB0IZ

LIZENZBESTIMMUNG

Allgemeine Lizenz für Amateurfunk Software (ALAS)

 

Copyrigth für den Text der ALAS (C) 1992 Hans Georg Giese, DF2AU

Hinter dem Berge 5

D-3300 Braunschweig

 

Dieses Dokument darf beliebig vervielfältigt oder verteilt werden, solange es nicht verändert wird. Für Anregungen, wie es zu verbessern ist, bin ich dankbar. (DF2AU @ DK0MAV.DL.EU)

 

 

1.

Vorwort

Diese Lizenz entstand aus der General Public Licence der Free Software Foundation (GPL). Ich habe versucht, den Sinn zu erhalten und mehr Klarheit hineinzubringen. Einige Passagen sind vollständig entfallen. Es ist aber jedem Nutzer freigestellt, an Stelle dieser Lizenz die GPL Bedingungen anzuwenden.

 

Der Sinn dieser Lizenz ist es, den Autor und den Anwender der Software zu schützen. Es sind daher einige Einschränkungen erforderlich und es entstehen auch einige Pflichten für den, der die mit dieser Lizenz verbundene Software weitergibt oder verändert.

 

Dies wird dadurch erreicht, daß die Software durch Copyright geschützt wird und der Nutzer durch diese Lizenz die Möglichkeit einer nahezu unbeschränkten Nutzung erhält.

 

2.

Geltungsbereich

Diese Lizenz gilt für jedes Programm oder Teil eines Programmpaketes, das eine Copyright Notiz ausgibt, die sich auf diese Lizenz bezieht. Im folgenden bedeutet "Programm" entweder das Programm oder einen Teil davon.

"Du" bist der Lizenznehmer.

 

3.

Deine Rechte:

Du darfst das Programm nutzen oder kopieren oder verteilen oder verändern, solange Du damit keine kommerziellen Absichten verbindest.

 

 

4.

Deine Pflichten:

 

4.1.

Du darfst den Copyright Vermerk und den Hinweis auf diese Lizenz nicht verändern und er muß bei jedem Start des Programms eindeutig für den Benutzer sichtbar sein.

 

4.2.

Du musst jedem Dritten, dem Du eine Kopie des Programms gibst, die gleichen Rechte einräumen, die auch Dir gegeben wurden. Du musst ihm auch die gleichen Pflichten auferlegen.

 

4.3.

Du darfst für die Weitergabe kein Geld verlangen ausser den Kosten für das Medium und Porto.

 

4.4.

Du darfst das Programm nur komplett weitergeben, so wie Du es bekommen hast.

 

4.5.

Wenn Du das Programm veränderst oder Teile davon für eigene Arbeiten verwendest - wörtlich oder verändert - so gelten die folgenden Punkte für das daraus entstehende neue Programm:

 

4.5.1.

Du musst deutlich sichtbar angeben:

- Deinen Namen und Deine Adresse und

- die Tatsache, daß Du das Programm geändert hast oder Teile des Programms verwendet hast.

 

4.5.2.

Du musst das Programm entweder mit dem kompletten Quelltext weitergeben oder jedem auf Verlangen eine Kopie des Quelltextes gegen eine Gebühr von maximal der Kosten des Mediums und der Portokosten aushändigen.

 

4.5.3.

Du darfst keine Beschränkungen aussprechen, die über diese Lizenz hinausgehen.

 

 

5.

Sonstiges

Du erhälst das Programm ohne jede Garantie für Funktion, Fehlerfreiheit oder Anwendbarkeit für eine bestimmte Sache. Du verzichtest auf jede Schadensersatzforderung, gleich aus welchem Grunde.

Mit der Nutzung des Programms erkennst Du diese Lizenzbedingungen vorbehaltlos an.

 

 

(Vers. 1.0, 13-OCT-92)

 

ConversD - Vernetztes Convers

DE DL9SAU (Bulletin-ID: DB0SAO068890)

Das Conversd Protokoll

Jahre hat es gedauert, bis das conversd Protokoll auch in der Software der Benutzer Einzug gehalten hat.

I. Grundsätzliches

 

Auf auf einige Fakten soll hingeweisen werden, da

o seit dem Zeitpunkt als da sich der conversd Link der Administration von verantwortlichen Sysops entzieht, schwerwiegende Probleme entstehen können. Das gross gewordene conversd Netz ist folglich weniger einfach zu überschauen wie es zu Zeiten war, als es sich nur über 3 Maschinen (die WAMPEn db0sao, db0id und df1tl) erstreckte.

o es viele Reimplentationen von Dieters Original-Code gibt und diese nicht vom Protokoll (dem von Dieter gesetzten Standard) abweichen sollten.
Nicht beeinflussen oder der Kreativität Einhalt gebieten möchte ich das Verhalten der verschiedenen conversd auf Userebene.

 

II. Fakten

 

o convers ist auf HP-UX entwickelt worden und der Daemon kann über WAMPES eine Verbindung mit anderen Hosts aufbauen; diesen Link nenne ich hier 'conversd Link', kurz 'conversd'.
Autor ist Dieter Deyke, <dk5sg>.

 

o Ein conversd, zu dem eine Verbindung aufgebaut wurde, meldet sich nicht mit einem Text. Einige von db3fl auf NOS portierte Versionen tun dies - das stört zwar nicht, man darf sich aber nicht darauf verlassen, daß der connectete conversd etwas zur Begrüssung sagt.

 

o Eine Verbindung mit conversd kann entweder als User oder als Host erfolgen. Ob es sich um einen User oder einen Host handelt, erkennt conversd an der Anmeldung (ein User sagt "/name <username> [channel]" während sich ein Host mit dem Host Command anmeldet).
Daraus resultiert, daß das conversd Protokoll keineswegs auf einen TCP layer angewiesen ist und oder mit SSIDs eine User connection von einer Host connection unterschieden werden muß, sondern conversd auch über ax25- oder NetRom Verbindungen abgewickelt werden kann.

 

o Die Usernames sollten 8 Zeichen lang sein, damit sie in den '/who' Listen nicht verstümmeln und private messages durch die zu tippenden Namen nicht zur Tortur werden. Gleiches empfehle ich für Hostnames.

 

o Das Namensfeld hat eine Grösse von 80 Bytes -> ein User- oder Hostname sollte nicht länger sein als 79 characters.

 

o Jeder conversd sollte im Stande sein, Zeilen bis zu 2048 Bytes Länge verarbeiten zu können.

 

o Korrekte channels sind 0 bis 32767.
Bei falschem Wert darf sich der User nochmals versuchen.

 

o Nur auf die erfolgreiche Anmeldung reagiert conversd -> Erst nach erfolgreicher Anmeldung kann der User andere Kommandos absetzen.
Hat sich ein User angemeldet, sagt z.B der conversd auf db0id "conversd @ db0id $Revision: 151 $ Type /HELP for help."
Hat er sich als Host identifiziert, werden ihm die User angemeldet. Bei Usern wird jede Zeile die mit '/' beginnt als Kommando interpretiert - alles andere wird auf dem momentanen Kanal ausgesand.
Bei conversd link Verbindungen gibt es nur Kommandos; Zeilen die nicht mit '/' beginnen oder falsche Kommandos werden im Unterschied beispielsweise zum SMTP Protokill nicht kommentiert und werden auch nicht an weitere conversd's im Netz weitergeleitet.

 

o Ein User kann sich auf mehreren Kanälen, gleichen Kanälen mehrmals, und mehreren Hosts gleichzeitig anmelden.

 

Meldet sich ein conversd beim anderen mit dem Host command an, wird beim Nachbarn eine ggf. noch bestehende alte conversd link Verbindung ausgetragen (sowie _alle_User_ gleichen Namens!).

Grund:
Hosts haben mit ihren Nachmarn max. EINE Verbindung und müssen bei der Wahl ihrer Linkpartner aufpassen, daß keine Schleifen entstehen. Das Protokoll selbst fängt Loops nicht ab; so hätte diese Unachtsamkeit verherende Folgen für das gesamte conversd Netz.

Man halte sich das Bild eines 'Baumes' oder 'Seils mit Knoten' stets vor Augen und bedenke das Verbot von netzartigen oder mehreckigen Strukturen!

III. Die HOST Commands

 

a) allg. Syntax, Verbreitung

 

Host Commands beginnen mit

/\377\200

direkt gefolgt vom eigentlichen Kommando, das gross oder klein geschrieben werden kann, z.B.

/\377\200UMSG

Dem Kommando folgt eine festgelegte Zahl von - bis auf den eigentlichen Text - üblicherweise klein geschriebenen Argumenten, z.B.

/\377\200UMSG dk6ku dc1ik Hi Olaf!

 

Bei Kommandos ohne 'text' werden zusätzliche Argumente nicht an die Nachbar-Conversd's weitergeleitet. Gleiches gilt für falsche Kommandos oder Zeilen die kein Kommando enthalten.

User sollten HOST (= Protokoll-) Commands nicht ausführen dürfen.

 

Ein Kommando wird i.d.R. vom einen conversd zum nächsten weitergeleitet und dort an die angelinkten conversd's verteilt bis es sich über das gesamte Netz verbreitet hat.

 

Jeder conversd führt die Kommandos aus, d.h. empfangenes

o "HOST" verarbeitet er, ohne es weiterzuleiten.

o "CMSG" versendet er an alle lokalen User und Nachbarn, die User haben oder Nachbarn haben, deren User wiederum auf dem Kanal sind.

o "UMSG" versucht er an jeden Adressaten des Namens (lokal und auch an bestreffende Hosts auf dem Weg zum user weiterleitend) zu verschicken.

o "INVI" versucht er lokal loszuwerden; schafft er es nicht, gibt er den INVI Wunsch an seine Nachbarn weiter.

 

Jeder Host bekommt nur ein Minimum an Informationen ab. Hat er keinen User (lokal oder weiterleitend an einen anderen conversd) auf dem Kanal angemeldet wo eine CMSG eintrifft, wird ihm diese auch nicht geschickt. Äquivalentes gilt für UMSGs oder erfolgreiche INVIs.

 

b) genaue Syntax

 

o /\377\200HOST myhostname

Hiermit meldet sich der conversd nach erfolgreichem Verbindugsaufbau bei seinem Nachbarn an. Der angesprochene conversd reagiert mit

/\377\200HOST hisname

um sich so indirekt bei dem conversd anzumelden von dem die Verbindung ausging.

Jeder trennt alle alten Verbindungen, die den gleichen Namen führen wie der eigene hostname.

Nun meldet er die User an und bekommt die User des anderen Hosts angemeldet.

Das HOST Command ist nur für den Nachbarn relevant und werden daher nicht weitergeleitet.

 

 

o /\377\200USER name host 0 oldchannel newchannel

Für Werte von 0-32767 erfolgt ein Kanalwechsel. Zur Anmeldung neuer User hat oldchannel den Wert -1. Zur Abmeldung eines Users der auf dem abgemeldeten Host sitzt nimmt newchannel den Wert -1 an.

Das USER Command erreicht jeden Teil des Netzes.

 

 

o /\377\200CMSG fromname channel text..

..ist die eigentliche convers Message eines Users auf einem bestimmten Kanal. Sie routet durch's Netz an alle Nachbarn, die einen User auf entsprechendem Kanal haben.

 

Das CMSG Command erreicht jeden Teil des Netzes.

 

 

o /\377\200UMSG fromname toname text..

..sendet <text> als 'Private Message' (also nicht für alle auf dem Kanal lesbar) an entsprechenden User durch's Netz.

 

Das UMSG Command durchläuft nur die Teile des Netzes die zu dem (/den) Host(s) führen, auf dem 'toname' eingelogged ist.

 

 

o /\377\200INVI fromname toname channel

Dieses INVI routet unser baumförmiges Netz entlang, ggf. bis zu dessen Ende, wenn der User nirgendwo gefunden wird. Eine Antwort bei Erfolg der Invitation erhält der Absender 'fromname' von entsprechendem Host in Form einer UMSG.

Das INVI Command läuft so weit unser baumartiges Netz entlang, bis die Einladung erfolgreich ausgesprochen wurde (z.B. an im OS eingeloggten 'toname' auf entsprechenden Hosts, mit dem Digi connecteten 'tonames', etc).

 

IV. Beispiel einer conversd connection

 

 

db0id->db0sao SYN

db0sao->db0id ACK

 

db0id->db0sao:

/\377\200HOST db0id

 

db0sao->db0id:

/\377\200HOST db0sao

/\377\200USER dc6iq-fred db0sao 0 -1 99

 

db0id->db0sao

HOST db0id

/\377\200USER db4ut db0id 0 -1 0

/\377\200USER dl9sau dl9sau 0 -1 3600

/\377\200USER dc1ik dc1ik-u 0 -1 3600

 

db0id->db0sao

/\377\200UMSG db4ut dc6iq-fred Hi!

 

db0sao->db0id

/\377\200USER dc6iq-fred db0sao 0 99 0

/\377\200CMSG dc6iq-fred Hi!

 

db0id->db0sao

/\377\200INVI dl9sau dk6ku 3600

 

db0sao->db0id

/\377\200UMSG conversd dl9sau *** Invitation sent to dk6ku @ db0sao.

 

db0sao->db0id

/\377\200USER dk6ku db0sao 0 -1 3600

 

db0id->db0sao

/\377\200CMSG dl9sau 3600 Hi Rudolf!

/\377\200CMSG dc1ik 3600 Hi Rudolf! - Sri, muß weg..

/\377\200CMSG dc1ik 3600 ..&tschuess!

/\377\200UMSG dc1ik dk6ku Nix gegen Dich persönlich :-)

/\377\200USER dc1ik dc1ik 0 3600 -1

 

db0sao->db0sao

/\377\200CMSG dk6ku Mann, der hat's mal wieder eilig..

 

[Angenommen der Link bricht zusammen:]

db0id->db0sau RST

 

[Jetzt würde db0id an dl9sau senden:]

db0id->dl9sau

/\377\200USER dc6iq-fred db0sao 0 0 -1

/\377\200USER dk6ku db0sao 0 3600 -1

V. Zukunftsprognosen

o Weltumspannendes conversd Netz (via KW, Sat, etc) -> Jeder User auf der Welt erreichbar durch INVI Befehl.

o Übermittlung der Vornamen von Usern ins Protokoll integrieren

o Alphanumerische Kanäle

o Reichweitenangabe -> Lokalrunden, Ortsrunden,...

o Entwicklung eines Protokolls, das netzförmige Strukturen gestattet

 

2 be continued...

- Thommy <dl9sau@db0sao>

 

[Alle Fussnoten von DG9EP]

 

 

SMACK = KISS + CRC

(Bulletin-ID: DB0SAO063654)

SMACK - Protokollbeschreibung

Version 1.0, Stand 27.02.91

von Jan Schiefer, DL5UE und Dieter Deyke, DK5SG/N0PRA

1. Einführung

Ende 1990 wurde unter den Stuttgarter Packet-Radio-Amateuren erstmals konkret über die Datensicherung zwischen TNC und WAMPES-Knotenrechner nachgedacht. Da bei anderen Packet-Knotensystemen bereits Datenverluste aufgetreten waren, überlegten wir uns, auf welche Art und Weise eine möglichst kompatible Erweiterung des KISS-Protokolles um eine Prüfsumme vorgenommen werden könnte.

Das Resultat dieser Überlegungen bekam den Namen SMACK (Stuttgarts Modifiziertes Amateurfunk-CRC-KISS. Dieses Dokument soll die Unterschiede zwischen SMACK und KISS erläutern und Implementierungen auf anderen Systemen ermöglichen.

2. Was ist KISS?

KISS wurde im Jahre 1986 von Phil Karn, KA9Q vorgeschlagen [KARN]. Für seine TCP/IP-Software benötigte er ein Protokoll, daß einen einfachen Zugang zu Packet-Radio unterhalb der AX.25-Protokollebene ermöglicht. KISS bietet einen Schicht 2a-Zugang. Aufgaben des TNC sind im wesentlichen nur noch die Zugriffssteuerung auf die Frequenz (Kanal-Belegt-Erkennung, P-Persistence-Verfahren) und die Wandlung der synchronen HDLC-Daten auf dem PR-Kanal in das asynchrone Format der RS232-Schnittstelle.

Das KISS-Protokoll regelt die Abgrenzung einzelner Pakete mit Delimitern, die Behandlung eventuell im Datenstrom auftretender Delimiter und definiert einen einfachen Kommandosatz zur Einstellung von TNC-Parametern. Es wurden Vorkehrungen getroffen, um auch TNCs mit mehreren Packet-Kanälen betreiben zu können.

3. Modifikation des KISS-Protokolles

Der Hostrechner kommuniziert mit KISS in Form von Paketen. Der Anfang eines solchen Paketes wird durch den Delimiter FEND gekennzeichnet.

Dann folgt das sogenannte Kommandobyte. Es gibt an, ob es sich um ein Daten- oder ein Kommandopaket handelt und welches Kommando gemeint ist.

Bis auf eine Ausnahme (Reset-Kommando = 255) benutzen alle Kommandos nur die unteren 4 Bit dieses Kommandobytes. Dies hat den Sinn, daß die oberen 4 Bit bei Multi-Kanal-TNCs den Kanal angeben können. So können 16 Kanäle einzeln parametriert werden.

 

Da uns weder 16- noch 8-Kanal-TNCs bekannt waren, haben wir das oberste Bit dieses Kommandobytes zweckentfremdet. Ist es gesetzt, so handelt es sich bei dem fraglichen Paket um ein Datenpaket mit CRC (nur bei Datenpaketen findet eine Prüfsummenberechnung statt!).

Bei solchen Paketen wird am Ende des Frames die Prüfsumme angehängt, und zwar das niederwertige Byte zuerst. Die beiden folgenden Abbildungen zeigen das Rahmenformat eines Datenpaketes einmal ohne und einmal mit Prüfsumme.

 

 

FEND

0x00

DATA

...

DATA

FEND

KISS-Rahmen ohne Prüfsumme

 

 

FEND

0x80

DATA

...

DATA

CRC LOW

CRC HIGH

FEND

Smack-Rahmen mit Prüfsumme

 

Es soll hier nochmals wiederholt werden, daß nur Datenpakete CRC-gesichert werden. Damit wird verhindert, daß keine Kommandos mehr an den TNC geschickt werden können, wenn sich Host und TNC über CRC/kein CRC uneins sind.

4. Umschalten von KISS auf SMACK

Ein SMACK-TNC arbeitet nach dem Einschalten im KISS-Modus, erzeugt also keine Prüfsumme. Sobald es das erste Paket mit CRC empfängt, schaltet es seine Senderoutinen ebenfalls auf CRC um. Dieser Betriebszustand kann dann nur noch durch einen Reset verlassen werden. Der Host verhält sich sinngemäss genauso.

Ist jedoch ein KISS-TNC angeschlossen, so wird es CRC-Frames vom Host aufgrund des ihm unbekannten Kommandobytes verwerfen und normal weiterarbeiten.

 

Diese Methode hat den Vorteil, daß sowohl KISS- als auch SMACK-TNCs abwechselnd an einem Host betrieben werden können, ohne daß ein Umkonfigurieren notwendig ist. Das soll durch eine Darstellung der beiden Fälle veranschaulicht werden.

 

 

Fall 1: KISS-TNC

 

Host

TNC

  • Sendet ein einziges Paket mit CRC, schaltet dann seinen Sender wieder auf Normal-KISS.
 
 

  • Empfängt einen Rahmen mit dem für ihn unbekannten Kommandobyte 0x80 und verwirft ihn.

  • Versendet KISS-Daten ohne Prüfsumme.
  •  
     

    • Versendet KISS-Daten ohne Prüfsumme.

     

    Fall 2: SMACK-TNC

    Host

    TNC

    • Sendet ein einziges Paket mit CRC, schaltet dann seinen Sender wieder auf Normal-KISS.
     
     

    • Empfängt einen Rahmen mit CRC-Kennzeichnung, schaltet seinen Sender auf CRC um.

     

    • Versendet KISS-Daten ohne Prüfsumme.
     
     

    • TNC sendet den ersten Rahmen mit CRC.

     

    • Empfängt einen Rahmen mit CRC-Kennzeichnung, schaltet seinen Sender auf CRC um.
     

    • Versendet SMACK-Daten mit Prüfsumme.
     
     

    • Versendet SMACK-Daten mit Prüfsumme.

     

    Unabhängig vom Sendezustand (CRC/kein CRC) werden empfangene Rahmen immer

    wie folgt behandelt:

     

    Empfangener Rahmen

    Aktion

    Kein CRC

    Rahmen weiterverarbeiten

    Mit CRC, Prüfsumme richtig

    Rahmen weiterverarbeiten

    Mit CRC, Prüfsumme falsch

    Rahmen verwerfen

     

    Dieses Protokoll setzt voraus, daß eine KISS-Implementierung ihr unbekannte Rahmen verwirft. Dies wird in der KISS-Spezifikation [] gefordert.

    4. CRC-Berechnung und Implementierungstips

    Dies ist nicht der richtige Ort, um die Theorie der zyklischen Redundanzüberprüfung (cyclic redundancy check, CRC) zu erläutern. Hierzu sei auf die Arbeit von Michael Roehner, DC4OX [ROEH] verwiesen. Dieser Abschnitt schildert nur die für eine Implementierung notwendigen Details.

     

    Als Prüfpolynom wird das CRC16-Polynom verwendet. Dieses hat die Gestalt

     

    X16 + X15 + X + 1

     

    Der CRC-Generator wird mit 0 vorbesetzt. Berechnet wird der CRC über alle Datenbytes einschliesslich des Kommandobytes 0x80.

     

    Bekanntlich wird im KISS-Protokoll die Abgrenzung der Rahmen mit dem FEND-Zeichen (0xc0) durchgeführt. Der Fall, daß dieses Zeichen im Datenstrom vorkommt, wird gesondert behandelt. Dieser Vorgang wird SLIP-Encoding genannt.

     

    Der CRC muß berechnet werden, bevor das SLIP-Encoding stattfindet, und überprüft werden, nachdem das SLIP-Decoding stattgefunden hat. Dafür gib es mehrere Grücnde:

     

     

    Die CRCs gehören also logisch zum KISS Layer.

     

    Die Berechnung findet wie folgt statt:

     

    Verschiedene Algorithmen für den CRC-Generator werden in [ROEH] beschrieben.

    Hier sei ein einfacher tabellengesteuerter Algorithmus in der Programmiersprache C angegeben, der den CRC eines Puffers (buf) der Länge n berechnet.

     

    static int calc_crc(char *buf, int n)

    {

     

    static int crc_table[] = {

    0x0000, 0xc0c1, 0xc181, 0x0140, 0xc301, 0x03c0, 0x0280, 0xc241,

    0xc601, 0x06c0, 0x0780, 0xc741, 0x0500, 0xc5c1, 0xc481, 0x0440,

    0xcc01, 0x0cc0, 0x0d80, 0xcd41, 0x0f00, 0xcfc1, 0xce81, 0x0e40,

    0x0a00, 0xcac1, 0xcb81, 0x0b40, 0xc901, 0x09c0, 0x0880, 0xc841,

    0xd801, 0x18c0, 0x1980, 0xd941, 0x1b00, 0xdbc1, 0xda81, 0x1a40,

    0x1e00, 0xdec1, 0xdf81, 0x1f40, 0xdd01, 0x1dc0, 0x1c80, 0xdc41,

    0x1400, 0xd4c1, 0xd581, 0x1540, 0xd701, 0x17c0, 0x1680, 0xd641,

    0xd201, 0x12c0, 0x1380, 0xd341, 0x1100, 0xd1c1, 0xd081, 0x1040,

    0xf001, 0x30c0, 0x3180, 0xf141, 0x3300, 0xf3c1, 0xf281, 0x3240,

    0x3600, 0xf6c1, 0xf781, 0x3740, 0xf501, 0x35c0, 0x3480, 0xf441,

    0x3c00, 0xfcc1, 0xfd81, 0x3d40, 0xff01, 0x3fc0, 0x3e80, 0xfe41,

    0xfa01, 0x3ac0, 0x3b80, 0xfb41, 0x3900, 0xf9c1, 0xf881, 0x3840,

    0x2800, 0xe8c1, 0xe981, 0x2940, 0xeb01, 0x2bc0, 0x2a80, 0xea41,

    0xee01, 0x2ec0, 0x2f80, 0xef41, 0x2d00, 0xedc1, 0xec81, 0x2c40,

    0xe401, 0x24c0, 0x2580, 0xe541, 0x2700, 0xe7c1, 0xe681, 0x2640,

    0x2200, 0xe2c1, 0xe381, 0x2340, 0xe101, 0x21c0, 0x2080, 0xe041,

    0xa001, 0x60c0, 0x6180, 0xa141, 0x6300, 0xa3c1, 0xa281, 0x6240,

    0x6600, 0xa6c1, 0xa781, 0x6740, 0xa501, 0x65c0, 0x6480, 0xa441,

    0x6c00, 0xacc1, 0xad81, 0x6d40, 0xaf01, 0x6fc0, 0x6e80, 0xae41,

    0xaa01, 0x6ac0, 0x6b80, 0xab41, 0x6900, 0xa9c1, 0xa881, 0x6840,

    0x7800, 0xb8c1, 0xb981, 0x7940, 0xbb01, 0x7bc0, 0x7a80, 0xba41,

    0xbe01, 0x7ec0, 0x7f80, 0xbf41, 0x7d00, 0xbdc1, 0xbc81, 0x7c40,

    0xb401, 0x74c0, 0x7580, 0xb541, 0x7700, 0xb7c1, 0xb681, 0x7640,

    0x7200, 0xb2c1, 0xb381, 0x7340, 0xb101, 0x71c0, 0x7080, 0xb041,

    0x5000, 0x90c1, 0x9181, 0x5140, 0x9301, 0x53c0, 0x5280, 0x9241,

    0x9601, 0x56c0, 0x5780, 0x9741, 0x5500, 0x95c1, 0x9481, 0x5440,

    0x9c01, 0x5cc0, 0x5d80, 0x9d41, 0x5f00, 0x9fc1, 0x9e81, 0x5e40,

    0x5a00, 0x9ac1, 0x9b81, 0x5b40, 0x9901, 0x59c0, 0x5880, 0x9841,

    0x8801, 0x48c0, 0x4980, 0x8941, 0x4b00, 0x8bc1, 0x8a81, 0x4a40,

    0x4e00, 0x8ec1, 0x8f81, 0x4f40, 0x8d01, 0x4dc0, 0x4c80, 0x8c41,

    0x4400, 0x84c1, 0x8581, 0x4540, 0x8701, 0x47c0, 0x4680, 0x8641,

    0x8201, 0x42c0, 0x4380, 0x8341, 0x4100, 0x81c1, 0x8081, 0x4040

    };

     

    int crc;

     

    crc = 0;

    while (--n >= 0)

    crc = ((crc >> 8) & 0xff) ^ crc_table[(crc ^ *buf++) & 0xff];

    return crc;

    }

     

     

    Die Speicherung der Tabelle benötigt 512 Bytes. Sollte für eine Speicherung dieser Tabelle das EPROM im TNC zu voll sein, so kann man sie wie folgt zur Laufzeit aufbauen:

     

     

    unsigned short Table[256];

    const int Rest[8] = { 0xC0C1, 0xC181, 0xC301, 0xC601, 0xCC01, 0xD801,

    0xF001, 0xA001 };

    main()

    {

    int i, j;

    unsigned short value;

     

    for (i = 0; i < 256; i++) {

    value = 0;

    for (j = 0; j < 8; j++)

    if (i & (1 << j))

    value ^= Rest[j];

    Table[i] = value;

    }

    }

     

     

    Wird dieser Algorithmus in Assembler codiert, so benötigt er deutlich weniger Platz als die Speicherung der Tabelle selbst.

    Die Theorie findet sich wiederum in [ROEH].

    5. Implementierungen

    Bisher wurde dieses Protokoll in folgenden Systemen implementiert:

    7. Ausblick

    Eine wünschenswerte Implementierung dieses Protokolles wäre insbesondere ein Paket-Treiber nach der 'Packet driver specification' [FTP]. Damit wäre eine Umrüstmöglichkeit für alle existierenden NET- und NOS-Versionen [TCPIP-Softwarepakete A.d.H.] ohne Änderung des Quellcodes gegeben.

    Aber auch jede andere Packet-Radio-Software, die KISS-TNCs einsetzt, könnte von der Fehlersicherheit des CRC profitieren.

     

    Diese Protokollbeschreibung hat vorläufigen Character. Die Autoren (dl5ue@db0sao, dk5sg@db0sao) sind für Verbesserungsvorschläge, Hinweise auf Fehler oder sonstige Kommentare dankbar.

     

    FLEX-CRC-KISS Verfahren (Ergänzung v. dg9ep)

    Dieses Verfahren für RMNC-Hardware ähnelt dem SMACK - Verfahren bis auf folgende Unterschiede:

    Für weitere Informationen verweise ich auf [FLX]

    Hinweise zum TNC4 (FALCon)

    Anl. Upload mit der TNC4-FALCon-Firmware (nicht DigiWare oder TermWare)

    de DG3DBI @ DB0IZ.DEU.EU

     

    Hallo TNC4 (FALCon)-User !

     

    Da ich in den letzten Tagen immer wieder zu den eingespielten Files und zur Handhabung der Uploadfunktion gefragt werde, möchte ich hier mal kurz erläutern wozu die Files gut sind und wie man einen Upload ausführt.

     

    Die Files mit der Extension .EPR sind zum direkten Brennen in ein EPROM gedacht. Es ist dazu kein weiteres Monitoreprom oder ähnliches gedacht, es gibt ja auch nur einen Steckplatz für EPROMs.

    Beim Brennen des EPROMs ist zu beachten, daß wenn das zur Verfügung stehende EPROM größer als das File ist, die Daten immer in den oberen Adressbereich gebrannt werden müssen, ansonst findet der Prozessor verständlicherweise sein Programm nicht. Außerdem sind die eingespielten Versionen immer mit 0 Waitstate, das heisst die EPROMs dürfen max. 100ns Zugriffszeit haben. Die EPROM-Files sind nicht für einen Upload gedacht und können deshalb auch nicht dafür verwendet werden.

     

    Die Files mit der Extension .UPL sind zum Softwaremäßigen Laden in das RAM des TNC4 (FALCon) vorgesehen. Diese Files können nicht in ein EPROM gebrannt werden, sondern nur zum Upload in Verbindung mit einem Hostmode Terminalprogramm eingesetzt werden.

    Befindet sich im RAM des TNC4 (FALCon) eine eingespielte Software, kann der Benutzer zwischen der Version und der Version im RAM wählen. Die Software im RAM bleibt auch nach einem Reset erhalten, da das RAM ja akkugepuffert ist. Jeder EPROMCode enthält eine Routine, die beim Hochlaufen des Controllers prüft, ob ein geladenes Programm vorhanden ist und gestartet werden soll. Befindet sich ein geladenes Programm im Speicher, aber es ist das EPROM gewählt, so wird verhindert, daß die EPROM-Software den RAM-Code überschreibt. Das Programm im RAM des TNC4 (FALCon) wird dabei gleichzeitig anhand einer Prüfsumme auf Veränderungen überprüft. Wird ein Fehler festgestellt, setzt die Software den Status auf ungültig und es wird dann der EPROM-Code ausgeführt.

     

    Zwischen den beiden Versionen (RAM/EPROM) kann mit Hilfe des bekannten Kommandos QRES umgeschaltet werden. Dabei wird allerdings auch ein Reset des TNC4 (FALCon) ausgelöst, das heisst ein Online umschalten ist nicht möglich. Durhc einfaches Eingeben von QRES wird ein Reset ausgelöst und auf den EPROMCode umgeschaltet.

    Um auf den Code im RAM zu schalten, muß das QRES Kommando mit einem Parameter versehen werden. Der Parameter muß im Bereich von 0 bis 255 liegen und gibt an, wie viele Restarts die RAM-Software laufen soll.

    Der mit dem QRES Kommando angegebene Parameter wird zum Setzen eines Zählers verwendet. Dieser Zähler wird bei jedem Reset um eins erniedrigt. Ein Reset tritt normalerweise nur bei einem Ausschalten der Spannungsversorgung auf, sofern er nicht vom User durch den QRES-Befehl manuell ausgelöst wird.

    Steht der Zähler auf 0 wird er nicht verändert und es wird die EPROM-Software gestartet. Bei jedem Wert von 1 bis 255 startet die Software im RAM. Wird also QRES 255 eingegeben läuft die RAM Software bis 255 Resets (Ausschaltvorgänge) aufgetreten sind. Durch eine Eingabe von QRES ohne Parameter oder QRES 0 kann sofort wieder aufs EPROM zurückgeschaltet werden. Tritt bei der Prüfsummenbildung der RAM-Software ein Fehler auf, wird der Zähler direkt auf 0 gesetzt und die Software aus dem EPROM gestartet.

     

    Wie bereits oben erwähnt, geht die RAM-Software auch bei einem Zählerstand von 0 nicht verloren. Durch erneutes Setzen des Zählers kann jederzeit wieder umgeschaltet werden.

    Die aktuell laufende Software (RAM/EPROM) sowie die Versionsnummer und der Zählerstand bei laufender RAM-Software können im normalen Betrieb mit dem @VER Kommando abgefragt werden. (Erst ab Version 1.40)

    Da jedes QRES-Kommando normalerweise von einem Reset gefolgt wird, wurde das Kommando im Hostmode zurückgestellt. Das bedeutet wenn der TNC4 (FALCon) sich im Terminalmodus befindet wird der Reset sofort nach dem Setzen des Zählers ausgeführt. Ist der Controller hingegen im Hostmode, so wird der Zähler gesetzt und der Reset erst nach dem Verlassen des Hostmodes ausgelöst.

    Damit wird verhindert, daß Hostmode Terminalprogramme nach der Eingabe des QRES Kommandos mit einem Resync abstürzen und noch geordnet verlassen werden können.

    Das Terminalprogramm SP lässt normalerweise die Eingabe des QRES Befehls im Hostmode nicht direkt zu. Dies lässt sich aber durch die Eingabe von CFG INI=QRES <Wert> umgehen.

    Sollte eine Eingabe des QRES Kommandos mit dem verwendeten Hostmode-Terminalprogramm nicht möglich sein, muß ein Standard-V24-Terminalprogramm (Telix, Kermit o.ä.) zur Eingabe verwendet werden.

     

    Der Upload einer neuen RAM-Version der Software kann nur durchgeführt werden, wenn aktuell die EPROM-Version läuft. Dies ist ja verständlich, da die RAM-Software ja nicht von sich selbst überschrieben werden kann.

     

    Zum Einspielen einer neuen Firmware oder Digiware Version ist daher am günstigsten wie folgt vorzugehen:

     

    1. Mit dem @VER Kommando prüfen, ob bereits die EPROM-Version läuft. Ist das der Fall, kann gleich zu Punkt 3 weitergegangen werden. Bei Versionen vor 1.40 gibt es den Befehl @VER noch nicht. Hier sollte 2. dann immer ausgeführt werden.

     

    2. Das Kommando QRES 0 eingeben. Geschieht dies im Terminalmode, wird sofort auf die EPROM-Soft umgeschaltet, ansonsten muß nach der Eingabe das Terminalprogramm erst verlassen werden.

    Im Regelfall werden beim Zurückschalten von einer RAM-Version auf die EPROM_Version alle Parameter der Firmware zurückgesetzt, da die EEPROM und RAM-Inhalte der Versionen verschieden sind.

    Die Firmware schaltet dann auf eine Baudrate von 2400 zurück.

    Damit die anschließende Kommunikation mit dem Hostmode-Terminalprogramm zum Upload funktioniert muß deshalb die Baudrate der V24 erst wieder mit dem @hbaud Kommando auf die gewünschte Baudrate gesetzt werden, da ein Upload mit 2400 Baud doch recht langwierig sein kann.

    Das Setzen anderer Parameter ist zum Upload jedoch in der Regel nicht notwendig.

     

    3. Besitzer einer TNC4 (FALCon)-RAM-Extension können gleich zu Punkt 4 übergehen, da bei Verwendung derselben Daten- und Programm-RAM getrennt sind und keine Einstellungen für das Shared-RAM vorgenommen werden müssen. Zum Upload der Digipeatersoftware ist die RAM Erweieterung auf alle Fälle erforderlich, da alleine die Software dann über 200 KByte umfasst und somit kein Platz mehr für Daten bleibt.

     

    Nun sollte bei laufender EPROM-Software die Verteilung des RAMs geprüft werden. Das muß mit Hilfe des @memtop Kommandos durchgeführt werden. Die einfache Eingabe von @memtop gibt das der EPROM-Software zugeordnete RAM zurück. Die Anzeige repräsentiert die der Software aktuell zugeordneten 4 KByte Blöcke für die Speicherung von Daten für den normalen Betrieb.

    Ist der Controller wie standardmäßig mit 256KB RAM bestückt, beträgt der maximal angezeigte Wert 256 / 4 = 64 Blöcke.

    Mit dem @memtop Kommando muß nun die dem EPROM maximal zugeordnete Größe zur Abspeicherung von Daten gesetzt werden. Das zu ladende Programm zählt natürlich nicht zu diesen Daten.

    Zuerst wird die Anzahl der für die RAM-Software benötigten Puffer berechnet. Dazu wird die Filegröße des Upload-Files durch 4096 geteilt. Der sich ergebende Wert muß jeweils auf eine ganze Zahl aufgerundet werden. Also z.B. 17,25 muß auf 18 aufgerundet werden.

     

    Nun ist der sich ergebende aufgerundete Wert von der vorhandenen RAM-Größe (64 bei einem 256K TNC4 (FALCon)) abzuziehen. Es ergibt sich in unserem Beispiel ein Wert von 64 - 18 = 46.

    Der sich ergebende Wert von 48 wird nun mit dem bei der @memtop Abfrage angezeigten Wert verglichen. Ist der von @memtop angezeigte Wert größer als der errechnete, muß @memtop auf jeden Fall neu gesetzt werden. Ist der Wert kleiner empfiehlt es sich @memtop ebenfalls neu zu setzen, um der Software jeweils den maximal möglichen Speicher zur Verfügung zu stellen.

    Stimmt der angezeigte Wert überein, kann gleich zu Punkt 4 weitergegangen werden.

     

    Einen neuen Wert kann man nun durch die Eingabe von @MEMTOP <Wert> spezifizieren. Der nun eingestellte Wert muß auf alle Fälle noch im EEPROM gesichert werden, da er nach jedem Reset von dort gelesen wird. Dies geschieht durch die Eingabe des Kommandos @update p.

    Danach muß ein Reset durch Eingabe von QRES 0 oder das Aus- und Einschalten des TNC4 (FALCon) ausgelöst werden, damit die neue Einstellung wirksam wird. Nach dem Reset muß bei einer erneuten @memtop Abfrage der korrekte Wert angezeigt werden, ansonsten wurde vermutlich eine Fehlbedienung vorgenommen.

    Es kann dann mit dem eigentlichen Upload fortgefahren werden.

     

    4. Nachdem nun sichegestellt ist, daß die EPROM-Version läuft und das RAM korrekt verteilt ist, kann der Upload ausgeführt werden.

    Dazu ist das Hostmode Terminalprogramm zu starten und auf den Kanal 1 zu wechseln, der zum Upload nicht mit einer Station verbunden sein darf.

    Nun ist das Kommando @upload 1 einzugeben. Die Firmware connected nun automatisch mit dem Call UPLOAD und wartet auf den Transferbeginn. Zum transferieren muß das Uploadfile nun im bekannten Binär-Transfermodus der gängigen Terminalprogramme an den Controller gesendet werden. Beim Terminalprogramm GP im File-Menü Binärdatei wählen, beim Programm SP mit dem SP Kommando SB <Filename> den Transfer starten.

     

    Sind alle Einstellungen korrekt gewesen, beginnt der Transfer und die Firmware gibt nach Beendigung die Prüfsumme über die empfangenen Daten aus. Diese Prüfsumme entspricht vom Verfahren her der Prüfsumme der Terminalprogramme und kann zur manuellen Überprüfung einer korrekten Übertragung herangezogen werden.

    Ist die Übertragung beendet, disconnected der Controller wieder automatisch und die Software befindet sich nun geschützt im RAM des TNC4 (FALCon).

    War eine Einstellung zur Ausführung des Transfers nicht in Ordnung, disconected der Controller direkt nach dem Start des Transfers und meldet den aufgetretenen Fehler. Folgende Fehlermeldungen sind möglich:

     

    Remote running -> Es läuft noch eine RAM-Version

    Invalid len -> Länge des Uploadfiles ungültig (fehlerhaftes File)

    Too long -> Nicht genügend RAM-Platz (@memtop verkleinern)

     

    Ist kein Fehler aufgetreten, kann nun die Uploadversion bei Bedarf mit @qres <Restartanzahl> gestartet werden. Ein Hostmodeprogramm muß nach der Eingabe wie oben beschrieben natürlich zum Reset erst noch einmal verlassen werden. Ob das Umschalten erfolgreich war lässt sich dann mit dem @VER Kommando leicht überprüfen.

     

    Da in der Regel die Lage der Parameter im RAM und dem EEPROM bei verschiedenen Version im RAM und EPROM inkompatibel ist, läuft die RAM- Version in der Regel dann mit rückgesetzten Parametern und 2400 Baud an. Dies gilt natürlich ebenfalls bei einem späteren eventuellen Rückschalten auf die EPROM-Version analog.

    Wenn die Version im RAM durchgehend benutzt werden soll, empfiehlt sich die Angabe von 255 bei QRES Befehl und eine gelegentliche Überprüfung des aktuellen Zählerstandes mit dem @VER Kommando, da bei jedem Ausschalten des TNC4 (FALCon) der Zähler um 1 heruntergezählt wird.

    Wenn die RAM-Version weiterlaufen soll, kann der Zähler dann jederzeit mit qres <Wert> aufgefrischt werden. Der dem Befehl folgende Reset vernichtet dabei keine Parameter, sofern beim Setzen die RAM-Version aktiv war.

     

    Viel Spass beim Upload der neuen Versionen

     

    73 de Werner DG3DBI @ DB0IZ

    RAM-Extension

    de DG3DBI @ DB0IZ.DEU.EU

     

    Hallo RAM-Extension-Nutzer !

     

    Ich spiele hier mal kurz die Lage der Brücken auf der TNC4 (FALCon) RAM-Extension ein. Mit der hier angegebenen Bestückung können sowohl Digiware als auch die Firmware ohne Einbuße von Arbeitsspeicher ferngeladen werden.

    Bei der Firmware braucht @memtop nicht reduziert zu werden, da der RAM-Bereich fürs Programm intern gesondert verwaltet wird.

    Betrachtet man die RAM-Extension von der Bestückungsseite her so, daß RAM 5 links und RAM 1 rechts liegt, ist oben rechts der Dekoder 74AC138 zu erkennen.

    Links neben dem Dekoder befinden sich zwei senkrechte Kontaktreihen.

    Die Reihe direkt neben dem Dekoder hat 7 Anschlüsse und spiegelt die Ausgänge des AC138 wieder.

    Links daneben befindet sich eine 6 polige Reihe, die die Chip-Selects der 5 RAMs sowie einem leeren Kontakt entsprechen.

     

    Es sind drei Brücken zu setzen:

    Ich gehe hier von der Bestückung der RAM-Karte mit 3 RAMs aus.

    Eins der RAMs kommt dabei von der TNC4 (FALCon) hauptplatine, da dort ja der Adapter eingesteckt wird. Gleiches gilt natürlich auch für den Dekoder 74 AC 138.

    Die erste Brücke liegt genau waagerecht und geht von der 6 poligen Reihe (2ter Pin von oben) zum 3ten Pin der 7 poligen Reihe (auch von oben gezählt).

    Die zweite Brücke ist diagonal eingesetzt und verbindet den 4ten Pin der 6 poligen mit dem 4ten Pin der 7 poligen Reihe (jeweils ab dem oberen Pin der Reihen gezählt).

    Die dritte und letzte Brücke ist wieder waagerecht und verbindet den 5ten Pin der 6 poligen mit dem 6ten Pin der 7poligen Reihe. Jeweils wieder von oben gezählt. Bei der angegebenen Brückenlage müssen dann die RAMs 2, 4 und 5 bestückt werden. Die anderen Fassungen bleiben leer.

    Wie bereits in der Aufbauanleitung zur RAM-Karte beschrieben, muß der Pin 30 und Pin 32 an mindestens einem RAM miteinander verbunden werden, da hier leider eine Brücke auf der Platien fehlt.

    Das kann entweder durch einen Draht unter der Platine oder das Einsetzen einer Brücke in eine freie Fassung geschehen.

     

    Vor dem Einsetzen der Erweiterung in TNC4 (FALCon) müssen noch die

    Jumper 2 und 4 auf TNC4 (FALCon) umgestéckt werden.

    Jumper 4 und Jumper 1 müssen zum Betrieb der Extension zur Platinenmitte hin gesteckt sein, Jumper 2 hingegen zum Platinenrand.

    Damit sind bei Verwendung der RAM-Karte Jumper 2 und 4 gegenüber der Normalkonfiguartion vertauscht.

     

    73, Werner

     

    Aufbau der TNC4 (FALCon)-RAM-Extension Platine

    de DG3DBI @ DB0IZ.DEU.EU

     

    Die TNC4 (FALCon)-RAM-Extension Platine ermöglicht die Aufrüstung des TNC4 (FALCon)-Arbeitsspeichers von 256 KByte auf bis zu 768 KByte. Dies ist zwar auch unter Verwendung von 512 KByte RAM-Bausteinen direkt auf der TNC4 (FALCon)-Karte möglich, jedoch sind die notwendigen 512 KByte (4 MBit) Chips nur schwer zu beschaffen und sehr teuer.

    Deshalb wurde die Erweiterungskarte entwickelt, die eine Erweiterung der RAM-Kapazität mit preisgünstigen 128 KByte (1 MBit) Bausteinen ermöglicht.

    Da die Platine in der Regel nur zum Einsatz bei Digipeatern notwendig ist und zu einem späteren Zeitpunkt die 4MBit Chips vermutlich günstiger und ab Lager lieferbar sein werden, ist die Erweiterungskarte nicht Industriemäßig hergestellt worden. Das heisst die 14 Durchkontaktierungen auf der Platine müssen von Hand vorgenommen werden.

    Prinzipiell sollte man beim Aufbau der Karte wie folgt vorgehen:

     

    Zuerst muß die Platine gebohrt werden. Dazu sollte ein 0,8 mm Bohrers verwendet werden. Der Einsatz von größeren Bohrern führt unter Umständen zu Verlust einzelner Lötaugen, da dann zu wenig Kupfer stehenbleibt.

    Beim Bohren der Platine muß die Platine auf jeden Fall mit der Bestückungsseite nach unten liegen. (Die Bestückungsseite ist an den großen Masseflächen und den Bauteilbezeichnungen erkennbar.)

    Nach dem Bohren sollte man sich nochmals davon überzeugen, daß auch alle Löcher gebohrt worden. Dies gilt insbesondere für ein Anschlußpad von C1, das direkt in einer breiten Leiterbahn liegt und somit nicht so gut zu erkennen ist.

    Ist die Platine fertig gebohrt, müssen zuerst die 14 Durchkon- taktierungen mit Hilfe blanker Drahtstücke beidseitig verlötet werden.

    Die 14 Durchkontaktierungen sind leicht auf der Bestückungsseite zu erkennen. Alle auf der Bestückungsseite sichtbaren dünnen Leiterbahnen sind mit reinen Durchkontaktierungen verbunden. (7 Leiterbahnen a 2 Durchkontaktierungen)

    Nachdem die Platine erfolgreich durchkontaktiert wurde, können die IC Sockel bestückt werden. Dazu ist die Platine so hinzulegen, daß die Bestückungsseite nach oben zeigt und rechts unten der Schriftzug RAM1 zu lesen ist.

    Nun ganz rechts den 32-poligen Sockel des RAMs 1 bestücken. Die Kerbe des Sockels/RAMs muß dabei nach oben - also in Richtung C1 - zeigen.

    Die weiteren 4 Fassungen für die RAMs sind dann von rechts nach links in der gleichen Orientierung zu bestücken. Die Fassungen stoßen dabei seitlich immer direkt aneinander an. Auf diesen Punkt ist besonders zu achten, damit nicht die Löcher für die später zu bestückende Steckerleiste geschlossen werden.

    Sind alle 5 RAM-Sockel eingesetzt können diese von der Rückseite angelötet werden. Zusätzlich muss der Pin 16 aller RAMs direkt auch von oben direkt mit der Massefläche verlötet werden. Bei den RAMs 1 bis 4 befindet sich dieser Pin auch schon direkt in der Massefläche auf der Oberseite und muß nur verlötet werden. Bei RAM 5 muß mit Hilfe von etwas Lötzinn die Verbindung etwas gezogen werden, da dort die Massefläche leider ausgespart wurde und der Pin des RAMs somit nicht direkt in der Kupferfläche liegt.

    Als nächstes ist die 16-polige Fassung für den Dekoder DEK einzusetzen. Die Kerbe muß dabei in die gleiche Richtung wie bei den RAMS zeigen. Die Position befindet sich oberhalb von RAM1/RAM2 links neben den Kondensatoren C1 und C2.

    Aber ACHTUNG: Beim Einsetzen des Sockels muß neben den Positionen von C1 (waagerecht) und C2 (senkrecht) eine senkrechte Lochreihe (8 Löcher) freibleiben. In diese freibleibende Reihe wird nachher eine Steckerleiste von unten eingesetzt. Es ist besondere acht zu geben, daß der IC- Sockel nicht fälschlicherweise in diese Reihe eingesetzt wird. Ist der Sockel korrekt eingesetzt worden befindet sich eine freie 8er Lochreihe unter der Dekoderfassung. Linksseitig schliesst sich direkt eine Massefläche mit der Inschrift C3 an die Dekoderfassung an. Nachdem die korrekte Position der Fassung nochmals kontrolliert wurde, kann man die Fassung von unten verlöten. Zusätzlich muß dann noch der Pin 8 des Dekoders von oben mit der Massefläche verlötet werden.

    Nun sind alle IC-Fassungen bestückt und es können die 6 Kondensatoren (100nF, Vielschicht-Keramik, Rastermaß 5,08 mm) eingesetzt und verlötet werden. C1 und C3 bis C6 werden waagrecht und C2 senkrecht eingesetzt. Die Kondensatoren C4, C5 und C6 sind dabei so einzusetzen, daß deren Bezeichnung genau mittig über den Kondensatoren zu erkennen ist. Die Bezeichnung von C3 liegt senkrecht oberhalb des rechten Bauteilpins von C3. Bei C1 und C2 kann eigentlich nicht falschgemacht werden.

    Nachdem die Kondensatoren nun von unten verlötet und gekürzt wurden, müssen die Masseanschlüsse der Cs jeweils noch von oben mit der Platine verlötet werden.

    Im Bereich der Cs 4 bis 6 bleibt links neben dem Masseanschluß des jeweiligen C jeweils noch ein Loch in der Massefläche frei. Diese Löcher sind überflüssig und waren ursprünglich für die Verwendung einer einseitigen Platine gedacht. Bei C1 verbleibt ein freies Loch rechts neben dem C in der Massefläche. Man braucht diese 5 Löcher nicht weiter zu beachten.

    Nun müssen die Steckerleisten zur Verbindung mit der TNC4 (FALCon) Hauptplatine von der Lötseite bestückt werden. Dabei kommen Steckontakte zum Einsatz, die beiderseits einen Stift haben. Man sollte sich vorher vergewissern, daß zumind. eine Seite dieser Leisten auch in die Original TNC4 (FALCon) IC-Fassungen passt.

    Die Steckerleisten fixiert man während des Einsetzens und Verlötens am besten mit einem passenden IC-Sockel, in den die Kontakte eingesteckt werden. Es werden zwei 8 und zwei 16 polige Kontaktstreifen benötigt. Eine Verwendung von Einzelkontaktstiften ist ebenfalls möglich.

    Die beiden Lochreihen für die 16 poligen Reihen befinden sich unterhalb von RAM2 und RAM3. Die beiden 8 poligen Leisten zum einen unter dem Dekoder DEK sowie rechts daneben. Zum Verlöten der Stiftleisten ist es meistens günstiger, diese nicht bis an den Anschlag einzusetzen.

    Zum Schluß müssen noch einige Verbindungen an den Lochreihen links neben dem Dekoder hergestellt werden. Dadurch werden die einzelnen RAMs den notwendigen Adressbereichen zugeordnet.

    Die genaue Position der Verbindungen ist der Tabelle zu entnehmen.

    Zusätzlich müssen noch die Pins 30 und 32 der RAMs an einer Stelle verbunden werden. Dies ist auf einen vergessene Verbindung im Layout zurückzuführen. Die Pins 32 und 30 der RAMs sind zwar von RAM zu RAM verbunden worden, aber nicht untereinander. Die Verbindung kann entweder durch einen Draht der auf der Unterseite der Platine angelötet wird oder eine Drahtbrücke, die in einen der leeren RAM-Sockel gesteckt wird hergestellt werden.

    Welche RAM Positionen zu bestücken sind ist ebenfalls der Tabelle zu entnehmen.

     

    73 Werner

    V24-Handshake

    de DG3DBI @ DB0IZ.DEU.EU

     

    Das geht selbstverständlich. Leider haben die Handshakeleituengen auf TNC4 (FALCon) keine V24 Treiber und Empfänger, weil die nicht mehr auf das Board passten. Vorhanden sind diese aber und liefern TTL-Pegel.

    Die sind also als /RTS und /CTS auf die Steckerleiste geführt, natürlich im TTL-Pegel und invertiert.

    Die /RTS Leitung wird noch nicht bedient, die braucht man aber auch nicht, denn TNC4 (FALCon) hat selber eine 1K großen RX-Puffer, den man im Hostmode ja nicht überfüllen kann. Außerdem ist die Schnittstelle ja sehr schnell.

    Die /CTS Leitung wird bereits bedient. Das ist hardwaremäßig im V25 kodiert und lässt sich nicht abschalten. Ich habe die Leitung daher auf dem Board über einen 47K auf Masse gezogen, sonst würde TNC4 (FALCon) ja nie senden!

    Wenn Du die Leitung also an einen normalen Ausgang einer PC-V24 anschliessen möchtest, mußt Du einen Empfänger oder simplen Transistorinverter dazufügen.

    Also z.B. 10 K Pullup gegen +5V an die TNC4 (FALCon) /CTS Leitung. NPN-Transistor als Schalter gegen Masse ebenfalls dran. Als Basiswiderstand reicht dann ein 22K (oder noch größer) wohl aus. Dort kannste dann die RTS vom PC anschliessen.

    Eventuell noch eine antiparallele Schutzdiode an der Basis gegen Masse (wegen der neg. Eingangssopannungen). Dann klappt das schon.

     

    Die Hardware macht es so, daß ein begonnenes Byte natürlich erstmal zu Ende gesendet wird, wenn CTS wechselt. Dann kommt aber erstmal nichts mehr, bis wieder freigegeben wird. Das entspricht also der CTS Leitung des TNC2.

    Ich finde die im PC verwendeten Bausteine allerdings zu diesem Zweck nicht ganz so schön, weil da RTS auch per Software bedient werden muß und nicht automatisch benutzt werden kann wie z.B. bei einem SCC oder einer SIO. Dort kann man einen Modus einschalten, der RTS automatisch deklativiert, solange etwas im RX-Puffer ist.

    Ich habe TNC4 (FALCon) auch schon mit 115200 baud und einer 16550er FIFO Chip betrieben. Allerdings gab es dann wegen der Interrupts öfter mal Probleme mit SMARTDRV, Diskcaches usw.

     

    73 Werner

    Warum ich KISS als HF-Schnittstelle nicht mag...

    ...beschreibt Burt,VE2BMQ recht treffend:

    KISS TNCs should be BANNED!!!

    (KISS @WW de:VE2BMQ 29.07.93 03:09 90 5268 Bytes)

    (Bulletin-ID: 36304_VE2FKB)

    ...

    Hi all. Now that I got your attention, I must admit that the subject line is a little strong. But only a little.

     

    We run a UHF regenerating repeater for backbone hub use on our network. In an effort to improve the operation of the network, I have monitored the data flow thru the repeater extensively. Let me add that the repeater often runs flat out with 95+% duty cycle which anyone has to admit is congested but due to the repeat function operates as a HTS free (Hidden Transmitter Syndrome free) environment even at close to 100% duty cycle.

     

    We have (had) 2 BBSs on the repeater that ran with G8BPQ switches and KISS mode TNCs. Early on during monitoring sessions, I noted problems with the KISS mode. I would observe repeated multiple frames, all the same, being transmitted during a single radio transmission. A little research revealed the cause. A KISS mode TNC DOES NOT communicate to the computer the status of the frames waiting to be transmitted. The computer sends the TNC one frame. It is a congested channel so the TNC waits for a break. Even when a break occurs, it may not transmit due to pPersistance timing. The computer does not know this. So it is waiting for a response. When it doesn't get one within a certain time, it resends the frame to the TNC. The TNC simply adds it to the transmit buffer. Depending on congestion, this can happen several times. Finally a break occurs, persistance allows the TX to happen, and ALL the contents of the TX buffer are sent as one long transmission.

     

    A further complication occurs when 2 such KISS TNCs are on a congested channel. One sends its long transmission. The other one has to wait even longer for a chance to transmit so it buffers even more frames. This goes back and forth leapfrog style until the ultimate packet is sent. One that contains all the retries allowed AND a disconnect. I have seen this happen on many occasions.

     

    This should be enough reason alone to strongly discourage the use of KISS mode TNCs on congested HTS free channels. However recent developments would suggest that there is even more reason to do so. The node associated with our repeater is part of a 4 node hub node stack with several higher speed dedicated links etc feeding into it. We have been experiencing severe "choke" problems on the node stack for the last 6 months or so. At first I blamed the hardware, but no amount of substitution did any good. Then I suspected firmware incompatibilities but no amount of changes to the firmware did any good on the affected channels.

    Finally last weekend I converted the KISS mode TNCs that were feeding into the node stack to full nodes. Lo and behold, the node stack now runs like it should, with minimal delays. I admit that I also did a lot of tuneups on the node site this weekend also, but they never did any good before.

     

    The multiple frames on the repeater have disappeared. The data flow has risen dramatically and all is well in packet land. (Well almost all is well if only I could get all the high speed links to work at the same time hi).

     

    So the moral of this bulletin is: Ban the KISS TNCs to the relative calm of quiet channels where they belong and run "proper" hardware on the high congestion routes. Or run some sort of "Host" firmware that can properly handshake with the computer. On dedicated point-to-point links KISS mode will also probably work ok since there is no TX hold-off but why risk the potential problems.

     

    Thanks for taking the time to read this bulletin. I would appreciate constructive comments and experiences from others running similar systems.

     

    Meanwhile keep on BRAPPPPPPPing and good networking....

     

    73 Burt VE2BMQ - MTL/WQC Network Co-Ordinator/NEDA Director/dogbody/etc.>>>

     

    DigiWare macht vieles möglich, womit man sich als Sysop unter Umständen *SEHR* unbeliebt machen kann....

    Ein Beispiel von Roland, DL1EER:

     

     

    Subj.: Auswirkung von Maxconnectbeschränkungen

     

    Hallo Falkner/Box- und DigiSysops

    Die FALCon-Software Digiware läßt es zu global einen Befehl einzusetzen, der die Userzahl für alle Calls auf einen Wert beschränkt.

    Bei DB0* und DB0* ist dieser Wert auf 2 gesetzt, die User können so 3 mal connecten.

    Dies hat in Verbindung mit dem S&F der umliegenden Mailboxen gravierende Auswirkungen.

     

    Ich habe mir mal den S&F-Verkehr bzw. den Verbindungsaufbau zu den Nachbarboxen angeschaut.

     

    [....]

     

    Da 3 OMs DB0PKE benutzen und zu der Zeit die maximale Connectzahl von DB0PKE bei DB0* erreicht ist, würde die Box auch beim vierten Anlauf ein busy bekommen. User kämen auch weiterhin rein. Der S&F wird damit drastisch unterbunden.

     

     

    Folgendes Gedankenmodell für DB0*

    Drei User benutzen DK0MWX und Jupps Box versucht den S&F mit ON*. Auch DK0MWX wird hier ein busy bekommen !

     

    Meine Bitte:

    Bis auf weiteres den Maxconnectbefehl nicht anwenden. Es ist zu klären ob der Maxconnect-Befehl der Watch-Optionen nicht lokal auf den Userport schaltbar gemacht werden kann. Wenn dies nicht möglich sein sollte bitte einzelne Calls, die gegen die seit kurzem von euch aufgestellten "Regeln" verstoßen mit diesen Maxconnectbeschränkungen explizit versehen.

    Bedenkt aber: Nicht jeder der 3x den Digi benutzt ist in 3 Boxen ![und genau deshalb sehe ich auch nicht ein, maxconnect Portbezogen zu machen]

     

    Dazu weiteres Gedankenmodell (hier Bsp für DB0*)

    Ich versuche DL2ECY bei DB0WHV zu erreichen. Dazu connecte ich über DB0* DB0ACC usw..

    Die Strecke hakt, ich baue via DB0* eine Strecke über PA auf.

    Gleichzeitig fällt mir ein, daß ich noch ein Date mit DG1EIH auf dem Userport habe. Ich connecte ihn.

    So nun bin ich dreimal bei DB0*. Ich erhalte einen Connectrequest von DL5JQ, da wie so oft an meinem Terminal alle Ports belegt sind disc ich erst mal einen Kanal. Leider ist DL5JQ dann schon mit einem anderen Call/Box verbunden.

    Ich versuche ihn über DB0* zu erreichen === BUSY

     

    Leute, das ist doch [ PIEP! ] !!!

     

    Sorry, aber für den MultiQsoOm ist das echt unerträglich!

    Nicht jeder der 3x im Digi ist, ist auch in 3 Boxen, bedenkt das bitte.

    Über die Interlinks dürften 5..10 Connects von einem Call kein Problem sein, sonst ist die Strecke zu langsam, hi.

     

    Fazit/Resume

    Der Effekt wird sein, daß mehr und mehr unbekannte und geliehene Calls au dem Digi erscheinen werden, bzw. die Neigung dazu steigt rapide.

     

    [....]

     

    Roland - DL1EER

    FlexNet-Router - Funktionsweise

    Kurze Übersicht

    Dieser Text entstand Stück für Stück; er mag deshalb etwas unverständlich sein...

    WIR und UNS meint immer den Digi. Der Einfachheit halber werden die Prozeduren beschrieben, die nur EIN Ziel betreffen. Dies ist keine Einschränkung, denn alle Ziele sind ja unabhängig voneinander.

    Prinzipien

     

     

    Das Routingprotokoll

    de George, DC1VL @ DB0GE.DEU.EU

    [überarbeitet von dg9ep]

     

     

    In diesem File wird lediglich das RoutingPROTOKOLL - also der Austausch von Daten wie Laufzeiten, Idents, Digiketten usw. - zwischen Digipeatern behandelt.

    Mehr will (und kann) dieser Beitrag nicht leisten. Aber für interessierte Laien wie mich ist auch diese Ebene schon von hohem Wert.

    Generelles zum Flexnet-Protokoll:

    Das Routing in FlexNet und dazu kompatiblen Systemen (BayCom, SNET) beruht auf einem im Ansatz genial simplen Protokoll, welches sich zur Kennzeichnung der verlangten Funktion einer einstelligen Zahl bedient, die an erster Stelle im Routing-Packet steht.

     

    Dazu können (müssen aber nicht) Parameter kommen, die im selben Packet mit untergebracht werden.

     

    Einige Pakete verlangen ein Antwortpacket vom Empfänger. Dies wird beim jeweiligen Pakettyp beschrieben.

     

    Besonders zu beachten ist, daß Flexnet-QSOs auch auf der AX25-Ebene, obwohl sie wie Klartext lesbar sind (keine Verschlüsselung a la NetRom), sich von normalen Frames durch die PID unterscheiden. Nur I-Frames mit PID "CE" (hexadezimal) werden akzeptiert, alles anderen PIDs führen zum sofortigen Disconnect (was der Schreiber dieser Zeilen leidvoll erfahren hat...).

     

    Nun aber in medias res:

     

    0 Die "0" ist Begrüßung und gleichzeitig eine Identifizierung.
    Sie dient gleichzeitig mit einem 2. Zeichen als Versionsidentifizierung. "Echtes" Flexnet hat die Kennzeichnung '00', Baycom benutzt '0<'. Dahinter folgt ein zweites Zeichen, daß die Kennzeichnung für die maximale SSID trägt. Diese wird dann automatisch in die Linkliste des Empfängers eingetragen. So wird z.B. aus DB0ME 0-15 bei DL0WST nach Linkaufbau DB0ME 0-10.

    Weitere Zeichen dahinter geben Optionen an, wie z.B. Version und Art der Knotensoftware und ob Headerkomprimierung vorhanden ist.

     

    1 Angabe der gemessenen Laufzeit
    Antwort auf ein mit 2 beginnendes Packet. Direkt hinter der 1 steht die gemessene und gemittelte Laufzeit zum Nachbarn.

     

    2 Anforderung der Laufzeit zum fragenden Knoten
    Der anfordernde Knoten schickt nur eine "2", gefolgt von 239 Leerzeichen in einem Packet. Der antwortende Knoten schickt dann die Laufzeit in o.g. "1"er-Frame als Folge von ASCII-Ziffern zurück.

     

    2 Sonderfall Baycom (Erweiterung des Flexnet-Protokolls):
    2DF3VI 7=HOMBURG Forward der Knotennamen, verbunden mit Laufzeitanforderung

     

    2DF3VI 7=HOMBURG Routing der Knotennamen und Laufzeit

    ! !!!

    ! !!+-------- Knoten-Ident

    ! !+--------- Trennzeichen ("ist Name")

    ! +---------- SSID des Knotens, dessen Name gerade übertragen wird

    +---------------- Digicall, 6stellig, mit Leerzeichen aufgefüllt

     

    Es können auch mehrere Knotennamen-Mitteilungen aneinander gehängt werden. Die Trennung der Mitteilungen erfolgt durch genau ein Leerzeichen. Das Format ist immer Digicall, SSID(bereich), Trennzeichen, Ident (evtl. Leerzeichen zur Trennung von der nächsten Mitteilung).

     

    3 Forward von bekannten Zielen mit SSIDs und Laufzeiten

    3db0abc001234 db0def001234 db0ghi001234 ... ...

    ! !!!

    ! !!!

    ! !!+--- Laufzeit (bis zu 4 ASCII-Ziffern)

    ! !! Laufzeit 0 löscht das Call aus der Destination-Liste!

    ! !+---- "bis" SSID (größte SSID)

    ! +----- "von" SSID (kleinste SSID)

    +------------Digicall, 6stellig, mit Leerzeichen aufgefüllt

     

    Hinweis:
    Bei SSIDs, die über 9 hinausgehen, werden die nächsten folgenden Zeichen in der ASCII-Tabelle benutzt (10-15 sind dementsprechend dann :;<=>? ).

     

    Der Routenforward findet jeweils nur in eine Richtung aktiv statt:

    3+ Es liegen Neuigkeiten vor; Anfrage diese Senden zu dürfen.

    3- Übergabe der Sendeerlaubnis an die Gegenstation; kann auch an einen Zielforward angehängt werden.

     

    4 unbenutzt (Zumindest habe ich diese Ziffer nie gesehen...)

     

    5 unbenutzt (Zumindest habe ich diese Ziffer nie gesehen...)

     

    6 Routenanforderung
    Packet zur Erforschung einer Route, die mittels "D <CALL>" bei einem Digipeater angefordert wurde. Die Antwort erfolgt durch ein Packet mit der Funktionsnummer "7".

    Bsp: Eingabe beim Node DF3VI-7 (Baycom): "D ON5ZS-1"

    6" 8DF3VI-7 DB0DIG ON5ZS-
    1
    ! !! ! ! !
    ! !! ! ! +----
    gesuchter Ziel-Digi (evtl. mit "-SSID")
    ! !! ! +----------- erster Nachbar-Digi (evtl. mit "-SSID")
    ! !! +------------- SSID des Start-Digis
    ! !+------------------- Start-Digi, auf dem die Route angefordert wurde
    ! +-------------------- Nummer des QSOs im anfragenden Digipeater,
    ! damit 7er Packets zugeordnet werden können.
    +-------------------------- Veraltenszähler, soll verhindern, daß ein 6er
    Packet (nicht zu verwechseln mit "Sixpack", hi)
    endlose Schleifen durchs Netz dreht.

    Hinweis: Der Pfad wird auf dem HINWEG zum Ziel von Digi zu Digi aufgefüllt und bleibt auf dem Rückweg unverändert.

    7 Antwort auf Routenanforderung
    Antwortframe auf Routingpacket Nr. 6 mit Rückgabe des kompletten Digipfades. Eintrag eines Diginamens in Großschrift: ein Digi, der das Flexnet-Protokoll beherrscht. Eintrag eines Diginamens in Kleinschrift: ein Digi, der das Flexnet-Protokoll nicht beherrscht. So erscheinen die betreffenden Namen dann auch in der Antwort des Einstiegs-Digis an den die Route anfordernden User.


    73 8DF3VI-7 DB0DIG DB0GE LX0PAC on5zs-1
    ! !! ! ! ! ! !
    ! !! ! ! ! ! +- gesuchter Ziel-Digi (evtl.mit SSID)
    ! !! ! ! +-----+----------- Zwischen-Digi(s) (evtl.mit SSID)
    ! !! ! +------------------------ erster Nachbar-Digi
    ! !! +-------------------------- SSID des Start-Digis
    ! !+-------------------------------- Digicall des Start-Digis
    ! +--------------------------------- Nummer des QSOs, das den Pfad
    ! angefordert hat.
    +--------------------------------------- Veraltenszähler (s.o. bei Nr. 6)

     

    Weitere Funktionsnummern wurden von mir bisher nicht entdeckt.

     

     

    Wesentliche Teile dieser Informationen verdanke ich Patrick DF3VI, der

    daher auch nicht unerwähnt bleiben soll.

     

    Vy 42 de George

    DC1VL @ DB0GE.DEU.EU

    Packet Radio Interessengruppe Saarpfalz

     

    DCF-77-Kram

    von Hans, DL7GAI, 25.07.93

    Zur Allmannshöhe 12

    78464 Konstanz

     

    DG9EP de DL7GAI (21:26 Local)->

    -----

    Es hat noch keine Dekodierung stattgefunden, oder die Dekodierung ist abgeschaltet.

     

    DG9EP de DL7GAI (21:26 MESZ)->

    ----

    Dekodierung hat stattgefunden, "Sommerzeit"

     

    DG9EP de DL7GAI (21:26 MEZ)->

    ---

    Dekodierung hat stattgefunden, 'Winterzeit'

     

    Weitere Info's zum Status des DCF-77 Dekoders erhält man mit dem Befehl DCF in der InfoBox. Die Bedeutung der Ausgaben auf den DCF-Befehl:

     

    done Set Nr. : 1 Sa 12.06.93 21:16:00 MESZ

    -> Letzte Dekodierung Nr. X am Datum/Uhrzeit

     

    overall Err. : 2 Pulse Detection Error

    -> Gesamtanzahl der fehlerhaften Dekodierungen und Grund, warum sie verworfen wurde.

     

    sequential Err. : 2

    -> Ist dieser Zähler >0, so waren die letzten X Dekodierungen fehlerhaft. Erreicht der Zähler den Wert von max. seq.Error, wird die Zeitzone wieder auf Local gestellt.

     

    max. seq. Err. : 272

    -> Nach soviel sequential Errors wird die Zeitzone wieder auf 'Local' gesetzt.

     

    Set-Interval : every 2 min

    -> Dekodierungsintervall

     

    next Set : 1 ' 11 "

    -> nächste Dekodierung in x min und y sec. "in progress" wenn die Dekodierung läuft.

     

    Die nächsten 2 Zeilen erscheinen nur, wenn die Dekodierung aktiv ist:

     

    Syncron Gap : wait sync.

    -> warten auf die Syncronisationslücke im Code oder 'found sync.' wenn die Lücke erkannt wurde.

     

    Code Position : 3

    -> Zeiger auf die Codeposition, d.h. welche Sekunde eben dekodiert wird.

     

     

    Bei einem Dekodierungsintervall > 9 min wird immer (wenn der Dekoder eingeschaltet ist) um 01:58:30 eine Dekodierung angeworfen, damit der Wechsel von MEZ<->MESZ pünktlich um 02:00:00 erkannt wird.

     

    Ein User kann nur DCF eingebenun die statistik abrufen. der Sysop kann mit:

     

    DCF OFF den Dekoder ausschalten

    DCF ON wieder einschalten

    DCF SET nummer den set intervall einstellen.

     

    Default ist momentan noch als Härtetest 2 Minuten eingestellt. Als Nummer kann zwischen 2 und 540 Minuten eingstellt werden.

    Um den Default zu ändern muss man folgendes beachten:

    dcf_sync_timer = nummer *60sec -10 - 60

    60 deshalb, weil ja eine laufende Dekodierung Datum/Zeit der nächsten beginneden Miunute beinhaltet. Sicherheitshalber gebe ich noch 10 sec dazu, sodass ca 10 sec bevor die Startlücke im Code kommt, der Dekoder auf die Startlücke spannt. Liese sich eventuell auch verringern.

     

    Bei jedem neu eingegebenen Setintervall wird der Rückschaltzeitpunkt des Infobox-Promptes neu berechnet. Also wieviele Dekodierungen in Folge in die Hose gehen dürfen, bis zurückgeschaltet wird. Das geschieht so nach ca 9 Stunden. Wird DCF abgeschaltet, so wird sofort zurückgeschaltet.

     

    Momentan überwiegen bei mir leider fehlerhafte Dekodierungen. Das liegt an der geringen räumlichen Entfernung der DCF-77 Antenne zu den Antennen der TRX.

    Immer wenn ein TRX sendet, und gerade ne Dekodierung läuft, kommt es durch Einstrahlungen zum Taktausfall am DCF-RX.

    Anschluss:

    Ich verwende den Conrad SMD-RX mit der dabei angegebenen Schaltung. Der Ausgang liefert /DCF als invertierten Takt. Deshalb hab ich einen NPN Transistor (BC109 o.ä.) als open Collector nachgeschaltet.

    Dieser Collektor geht über 1 kOHM zum port 0 bit 7. Pull up auf der FALCon-print bleibt drinn! (the V25 will thank u 4 protection hi ... ich will den Port nicht killen )

    Evt. könnte man mit der Dekodierung auch den RX einschalten, aber der RX braucht mit den 2 Low-Current LED's nur ca 2-3 mA!

    Prinzip:

    In FD_MAIN.MAIN wird jede Sekunde der dcf_count um 1 erhöht.

    Wenn der dcf-count >= dcf_set_timer ist, wird die Dekodierung angeworfen. (Berechnung des dcf_set_timer in FD_INFO im cmDCF) do_dcf wird true. und dann gehts in fd_timer.newint08 ab.

    Ich habe den Dekoderkram aus fd_timer in fd_dcf gepackt. Wegen der Kompaktheit.

     

    dcf_pulse_detection lauert auf die Impulse, erkennt die Startlücke und und zählt die Impulselängen in 10ms Schritten.

    Falls die Startlücke >5 sec ist, kann es sein, daß

    Gewitter ist am wahrscheinlichsten, da es bei dcf-77 ne reserve Ant und Reserve TX gibt.

    Der Betrieb des Reservekrams wird im Code angezeigt! Die Antennen sind ca 3 km auseinander. wenn es ordentlich fotografiert ähm, blitzt und donnert, dann schalten sie sogar komplett ab.

     

    Ebenso erkennt die Impulserkennung sogenannte pulse detection errors d.h. wenn durch ne Störung ein Impuls zu lange wird, also > 200ms (das kommt bei mir häufig vor; TRX 70cm strahlt in den RX)

    Ich summiere dann die einkommenden Impulse auf, bis ca 250 = 2,5 sec erreicht sind. aber hm.. wieso hab ich das so gemacht ? weis ich nicht mehr. wohl damit zur nächsten dekodierung etwas pause entsteht.

     

    Sind alle 59 (0-58) Impulse eingelesen wird dcf_ok TRUE

     

    Beim nächsten newint08 durchlauf wird dann dcf_compute_time angesprungen.

    Dort wird erst nochmals die Schwelle für die 0/1 Erkennung aus den Zeiten für die ersten 14 Bits gemittelt. Dann alle 59 Bits im Array auf 0 oder 1 gesetzt.

     

    Dann kommen wichtige Prüfungen:

     

    Erst mal parity check ( taucht aber nicht viel... )

    Dann Bit 20. das muß immer log. 1 sein.

    Es kommt öfters vor, das parity ok aber durch Störungen Bit 20 = 0 ist

     

    Dann range-check weekday. Trotz parity ok (ich sach ja:taucht nix) kommt es öfters vor das weekday = 0 ist ( sollte 1-7 sein) also checke ich auch noch ob <1 oder >7

     

    Dann wird aus dem Kram Datum/Uhrzeit berechnet.

    Trotz allen Check's kommt es ab und an vor, dass ne unsinnige Uhrzeit und Datum rauskommt. Also zuguterletzt checke ich noch, ob das dekodierte Jahr gleich oder +1 des RTC Jahres ist; andernfalls wird verworfen.

     

    War alles ok, dann wird der Kram für die Statistik (cmDCF) generiert, Datum in die rtc geworfen und dcf_set auf true gestellt.

     

    Ab dann wird in newint08 gepüft, ob wieder ein Impuls kommt. Wenn ja, dann wird die rtc-zeit gesetzt.

     

    Die eigentliche Synchronisation macht FD_MAIN.DOEVERYMINUTE. Das hab ich umgebaut und damit auch doppelte Conv-Timestamps eliminiert. Also beim Aufruf wird Datum und Uhrzeit geholt. Dann mit tc_minute=systime.sec synchronisiert.

    Ist systime.sec=0 wird DOEVERYMINUTE normal abgearbeitet, ansonsten wars das schon.

    Nen "mitlaufenden Sekundenzeiger" hab ich in newint-08 realisiert. Habe für Testzwecke FD_DIV.L_UHRZEIT gebastelt. Also so wie uhrzeit aber eben mit Sekunden.

    Schaltsekunden werden nicht erkannt. Ich finde das ist etwas viel Aufwand, denn so oft kommt das nicht vor.

     

    So das wars schon.. mehr fällt mir dazu nicht ein. Hoffentlich hab ich nix vergessen hi

     

    vy 73 de Hans

     

    PS: Alles Mumpitz und ungenau. Laut neuesten Forschungsergebnissen von Rohde&Schwarz muß man pro 300KM Entfernung vom DCF-TX mit ca. 1ms ( eine Millisekunde!) Abweichung rechnen. Das ließe sich mit GPS eliminieren. Leider ist das System von R&S vom Preis her nicht gerade erschwinglich. Hätte ich die Kohle dafür in der Hosentasche, dann hätte ich wohl ständig Löcher drinne hihi Sobald sich als Amateur GPS nachbauen läßt, gibt’s wohl FD_GPS?

     

    [GPS gibt es bei Conrads für 0,5 KMark]

    TNC-4/FALCon Interface für Conrad SMD-DCF-RX:

     

    Anscheinend ist bei den neueren Modulen keine Applikation dabei. Hier meine Lösung (Letzter Transi, der 18k und der 1k R hab ich dazugebastelt; der Rest ist aus der damals beiliegenden Applikation, hi).

     

    Das SMD-Modul hat ca. 11,2 * 30 mm. Auf der Lötseite ist das TFK IC U2775B. es sind 4 Draehte herausgefuehrt:

     

    Blau

    Masse

    Rot

    + 1.2 - 3,2 V

    Weis

    Inhibit (mit Rot, also Plus vom Modul, verbinden )

    Gelb

    Impulsausgang.

     

     

    Die rote LED blinkt im DCF-77 Takt. die beiden NPN's sind BC 107/8/9 C oder BC546/7/8C. der PNP BC177/8/9B oder BC556/7/8B. Mit einem weiteren Transistor ließe sich das Modul noch aktivieren.

    habe im Code schon vorgesehen. das ist der Kram mit Bit 6 . ist noch drin da ich mir mit einem 74ls244 uns 8*2mA LEDs nen parallel-port moni gebastelt habe.

     

     

    Aber das aktivieren ist nicht nötig, da der RX mit der Beschaltung nur etwa 2,5ma an 5 V zieht..

    Literatur

    [CORN] Cornelius, Werner, DG3DBI: "FACLon User Guide", Bochum 1992, beim Autor

    [FLX] Flexnet Gruppe Darmstadt: "RMNC/FlexNet-Software 3.1a, Sysop Dokumentation",o.O., 1992, S.33

    [FTP] FTP Software, Inc.; PC/TCP Version 1.09 Packet Driver Specification; Wakefield, MA 1989

    [KARN] Karn, Phil, KA9Q; Proposed "Raw" TNC Functional Spec, 6.8.1986; veröffentlicht in den USENET-News;

    [ROEH] Roehner, Michael, DC4OX; Was ist CRC?; veröffentlicht im Packet-Radio Mailbox-Netz, Mai 1988

    [SCHAEP] Schäpers, Arne, "Turbo Pascal 5.0", Addison-Wesley, 1988

    [SCHI] Schiefer, Jan, DL5UE; WAMPES - Weiterentwicklung; Vortrags-Skriptum des 5. überregionalen Packet-Radio-Treffens; Frankfurt 1989;

    [TAN] Tannenbaum, Andrew S.: "Computer Networks"; Prentice Hall International; Englewood Cliffs, 1989

    Schaltungen

    Schaltung 1

    Schaltung 2 Impulskontrolle und Open Collektor Treiber

     

     

    Tabelle 1 - Befehlsvergleich

     

    Index

    .Anfang Index.

    .Ende Index.