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.

Ü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.

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.

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!

ClkModus $08; SIMPLEX/DUPLEX; NRZI=0

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!)

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

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

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).

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.

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.

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

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!

Zur Eingabe des Aktuell Textes ist vom Sysop das Kommando

WRITE AKT

einzugeben. S. WRITE

<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

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"

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.

Man kann diesen Befehl aber auch abkürzen:

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.

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.

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).

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

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.

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:

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.

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.

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.

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.

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.

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.

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!

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.

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

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.

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.

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

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

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

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

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

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

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

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

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

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

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.

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.

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:

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

P p3 SMACKSTART 2 io 760 IRQ 3 baud 4800 SMACKINIT

P p3 SMACKSTART 2 io 760 IRQ 3 baud 4800 SMACKINIT

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

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

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

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

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

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).

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.

(Nur PC)

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

Beispiel:

P p3 IPXSTART 3

Systeminterne Bedeutung (Treiber) - Nicht verwenden

Systeminterne Bedeutung (Treiber) - Nicht verwenden

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)

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)

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.

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

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

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

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

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.

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.

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

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

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

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

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.

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.

sich als SYSOP kennzeichnen (wie bei DIEBOX).

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)

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.

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

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

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.

Upgeloadetes Programm oder Code im EPROM neustarten.

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.

(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

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

RESTART 17

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!

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

SETD 31101991

SETT 1230

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.

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.

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.

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

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.

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

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:

* 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

Löscht einen mit WRITE erfassten Text

Umbenennen eines mit WRITE erfassten Textes.

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

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.

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

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

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!!

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

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

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

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

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

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

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.

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.

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.

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

Im Folgenden nun die speziellen Sysop-Kommandos dazu

(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.

(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.

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.

(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.

<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.

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

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:

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.

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

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!!!

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.

<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

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

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

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

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.

(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).

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

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

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

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:

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.

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.

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.

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

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

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

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

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).

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.

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.

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.

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.

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.

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

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.

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

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?

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...

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:

Channel=Kanalnr.

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

Uhrzeit und Datum an dem der jeweilige User sich einlogte

Anzahl der Byte die er schrieb

Anzahl der Byte die er bei privaten Nachrichten schrieb.

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)

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?

*** 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

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.

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

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

Infotext über Station und Soft- und Hardware abrufen.

Wird vom Sysop mittels des Befehls WRITE INFO erzeugt.

Liste der bestehenden Linkverbindungen, und deren Nachbar-Digis.

Man kann auch ein selektives Argument angeben:

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:

BEMERKUNGEN

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

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).

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.

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:

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.

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

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

Beispiel:

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

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.

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.

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:

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.

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

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:

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.

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.

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.

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

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

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.

Nur PC-Version:

Sonstiges:

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)

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.

TIMER.pbEnabled

mBuf.Txed

mBuf.ptTimer

RootRxFree

u.a.

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

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....

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

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

Nicht verwendbar sind:

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

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 :)

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.

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.

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.

Kein Problem.

s. DigiWare

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.

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

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).

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

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

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.

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

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).

Kontaktaddresse für Fragen zu DigiWare und TermWare

Kontaktaddresse für Fragen zum TNC4 (FALCon)

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:

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)

DE DL9SAU (Bulletin-ID: DB0SAO068890)

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

Auf auf einige Fakten soll hingeweisen werden, da

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!

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

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

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.

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.

..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.

..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.

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).

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

2 be continued...

- Thommy <dl9sau@db0sao>

[Alle Fussnoten von DG9EP]

(Bulletin-ID: DB0SAO063654)

Version 1.0, Stand 27.02.91

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

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.

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.

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.

KISS-Rahmen ohne Prüfsumme

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.

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

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

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

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:

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].

Bisher wurde dieses Protokoll in folgenden Systemen implementiert:

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.

Dieses Verfahren für RMNC-Hardware ähnelt dem SMACK - Verfahren bis auf folgende Unterschiede:

Für weitere Informationen verweise ich auf [FLX]

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:

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

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

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

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

...beschreibt Burt,VE2BMQ recht treffend:

(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.>>>

Ein Beispiel von Roland, DL1EER:

Subj.: Auswirkung von Maxconnectbeschränkungen

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.

Drei User benutzen DK0MWX und Jupps Box versucht den S&F mit ON*. Auch DK0MWX wird hier ein busy bekommen !

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]

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.

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

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.

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.

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:

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

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

overall Err. : 2 Pulse Detection Error

sequential Err. : 2

max. seq. Err. : 272

Set-Interval : every 2 min

next Set : 1 ' 11 "

Die nächsten 2 Zeilen erscheinen nur, wenn die Dekodierung aktiv ist:

Syncron Gap : wait sync.

Code Position : 3

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.

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!

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]

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:

.Ende Index.