From: DL9NEC @ DB0SIF.#HES.DEU.EU (Sebastian) To : GP @ DL Hallo, liebe (X)YLs und OM, die Datei GP.FAQ, die ich im Anschluß an diese MSG einspielen werde, ist die Zusammenfassung der in dieser Rubrik desöfteren gestellten Fragen und deren Antworten darauf. Diese Antworten sind teilweise von mir nach bestem Wissen und Gewissen beantwortet worden, teilweise habe ich mich auch Zitaten aus Bulletins in dieser Rubrik beholfen. Ich hoffe, durch dieses FAQ ("Frequently Asked Questions") dazu beitragen zu können, endlich eine regelmäßige Wiederholung der darin enthaltenen Fragen in dieser Rubrik zu bremsen und damit sowohl für die Fragensteller ein gutes Informationsmittel zur Verfügung zu stellen wie auch den - sich bisweilen doch etwas genervt zeigenden - antwortenden OM eine Möglichkeit zu geben, ihre Antwort einfach dem FAQ zu entnehmen und nicht mehr jedesmal ihre Antwort neu verfassen zu müssen. Daher hoffe, ich daß das FAQ den Wünschen beider Seiten weitgehend entspricht. Verbesserungsvorschläge nehme ich dankend entgegen und werde sie in der nächsten "Auflage" berücksichtigen. Vy 73 de Sebastian DL9NEC @DB0SIF.#HES.DEU.EU ---------------------------------------------------------------------------------- Stand: 22.04.1995 FAQ GRAPHIC PACKET Frequently Asked Questions about Ulf's, DH1DAE, 'famous' Graphic Packet ============================================================================== 1. Aussendung von GP-Meldungen im RX-Schirm unterdrücken Q: Am Ende eines Speichervorgangs für ein 7PLUS- oder AutoBIN-File antwortet GP immer mit einer Meldung, die angibt, wie viele Daten in welcher Zeit mit welcher Effektivbaudrate übertragen wurden und ob der Dateitransfer korrekt war. Diese Meldung wird im Empfangsfenster angezeigt und auch an den QSO-Partner ausgegeben. Wenn ich allerdings Dateien aus einer Mailbox auslese, wird die Meldung ebenfalls ausgesandt, worauf dann natürlich eine Fehlermeldung zurückkommt. Wie läßt sich dies vermeiden? A: Die Eintragung der Mailbox in die Datei NAMES.GP als Typ B> sorgt dafür, daß diese Statusmeldungen nur auf dem Bildschirm angezeigt, jedoch nicht ausgesandt werden. >>> Beispiel: B>DB0SIF Mailbox Giessen; D>DB0BBG B>DB0SIF Mit diesem Eintrag in die Datei NAMES.GP wird DB0SIF als Mailbox dekla- riert. Ist DB0SIF hingegen als Terminal (Typ T>), Node (Typ N>), Digipeater (Typ D>) oder FlexNet-System (Typ F>) eingetragen oder aber besteht überhaupt kein Eintrag der Station in der NAMES.GP, so wird die Statusmeldung auch an den QSO-Partner ausgesandt. Eine weitere Möglichkeit hat OM Ronald, DL1DWW, recht schön beschrie- ben: DL1DWW > GP "Man kann das auch tun, indem man waehrend des QSOs mit der Box die Kombination betaetigt und die Frage nach dem Typ mit "B" beantwortet. Letzeres funktioniert nur bei der DOS-Version und hat den Vorteil, dass der Connectweg mit eingetragen wird und man bei naechsten Mal nur noch das Zielrufzeichen zum Connecten eingeben muss. Diese Route kann man natuerlich auch von Hand eintragen." In der OS/2-Version von GP funktioniert es jedoch ebenfalls, wie OM Stefan, DL1ELY, schreibt: DL1ELY > GP 15.04.95 12:43 @DL "Auch bei GP/2 gibt es wie bei GP WÄHREND des laufenden Betriebs eine Gegenstation als Mailbox oder Digi einzutragen. Was bei GP/Dos "ALT-N" heißt, heißt bei GP/2 "ALT-P" (Menüpunkt "QSO", dann "Parameter". Hier wird im oberen Teil des Dialogs das Call der Gegenstation, ein eventueller Name (ist natürlich leer, wenn die Station noch unbekannt ist), und der Typ der Gegenstation angezeigt. Nun klickt man einfach auf den Radio-Button "Mailbox", und dann auf "Speichern". Nun bestätigt man das darauffolgende Eingabefeld, und fertig! Die gegenstation sollte mit SOFORTIGER Wirkung als Typ [B] abgezeigt werden Falls nicht, muß man neu connecten, spätestens dann klappt es, und man ist diesen "GP-Fehler" los,hihi." 2. Unterschiede der GP-Versionen ab V1.61 Q: Was sind die Unterschiede zwischen GP V1.61, GP V1.61a und GP V1.61b? A: GP V1.61 wies einen kleinen, unschönen Fehler auf: Beim Abspeichern von AutoBIN-Dateien wurde ein evtl. im BIN-Header (#BIN#...) angegebener Dateiname für die abzuspeichernde Datei nicht übernommen, sondern die Datei wurde automatisch im Format . abgespeichert, wobei das Rufzeichen der Gegenstation ist und eine fortlaufende dreistellige Nummer, beginnend mit *.000. Dieser Bug wurde in der Version 1.61a besei- tigt. Leider kam dabei ein neuer Fehler hinzu: Beim Speichern einer Text- datei mit '//W ' konnte das File nicht mehr vom QSO-Partner mit '//W OFF' geschlossen werden; die Datei blieb geöffnet. Außerdem wurde bei der Version 1.61a die CRC für die /CHECK-Option beim Start von GP nicht angepaßt, so daß bei deren Benutzung zwangsläufig eine Viruswarnung auf dem Bildschirm erschien. Beide Fehler sind durch die Version 1.61b ausgemerzt. Am sonstigen Funk- tionsumfang hat sich nichts geändert. 3. Probleme mit Logitech-Maus Q: Unter GP wird meine Maus nicht erkannt. Ich kann daher GP nur mit Hilfe der Buchstabenkombinationen bedienen. Ich benutze eine Logitech-Maus des Typs "LogiPilot". Woher kommt dieser Fehler und wie läßt sich Abhilfe schaffen? A: Vermutlich wird die Maustreiberversion 6.3 verwendet. Gegenüber früheren Versionen arbeitet diese - aus ungeklärten Gründen - nicht mit GP zusammen. Möglicherweise wird ein Interrupt benutzt, den entweder auch GP verwendet oder aber den TFPCX anspricht. Leider habe ich die Version 6.3 noch nicht mit einem TNC getestet, kann daher also auch nicht sagen, ob es an TFPCX oder an GP liegt. Wer es weiß, kann mir gerne schreiben. Abhilfe kann nur entweder durch die Anschaffung einer neuen Maus (die weniger schöne Möglichkeit, hi) oder durch Austausch des Treibers gegen eine frühere Version (z.B. V6.2) geschafft werden. 4. Zwei TNCs unter GP Q: Gibt es eine Möglichkeit, GP an zwei TNCs gleichzeitig zu betreiben? A: Auf diesem Gebiet habe ich selbst wenig Erfahrung, da ich nur einen TNC besitze. OM Patrick, DF3VI, hat jedoch vor einiger Zeit eine Lösung in dieser Rubrik veröffentlicht: DF3VI > GP 24.08.94 08:15 @DL "Ich hatte bereits zur Verwunderung mancher vor einigen Wochen in der Rubrik SP angedeutet, daß es durchaus möglich ist, mit GP auch ZWEI TNCs zu betreiben. Allerdings geht das NICHT an nur EINER Schnittstelle, und es geht auch nicht ganz ohne einen kleinen "Trick". Dieses Geheimnis heißt KISSMODE, und man braucht dazu TFPCX in seiner neusten Version 2.10 . Mit einem kleinen Batch-File kann man dann per KISSINIT zuerst die TNCs in den KISS-Mode schalten, und danach TFPCX und dann GP aufrufen. Dieses empfiehlt sich aber nur auf halbwegs schnellen Rechnern, also nicht wundern wenn auf 286ern nacher (besonders mit 9k6-Betrieb) nur noch wenig dekodiert wird. 386er (und besser) haben zudem den Vorteil, daß durch Nutzung des UMB TFPCX auch HOCHgeladen werden kann, und dadurch im konventionellen DOS-Bereich kein Speicher verloren geht (ansonsten wirds ENG!). Alles weitere ergibt sich aus der UPDATE-Docu von TFPCX 2.0 auf 2.10 ." In einem anderen Beitrag gibt OM Patrick, DF3VI, noch ein Beispiel für eine Batchdatei, mit der GP an zwei TNCs (hier: einer an COM2, einer an COM4) angepaßt wird. DF3VI > GP 18.02.95 22:28 61 Lines 2869 Bytes #305 DB0AIS@DL "[...] Die Initialisierung der TNCs und der Start des Systems erfolgt zweckmäßi- gerweise in einem Batchfile wie folgt (RS232-Parameter anpassen!): cd\gp kissinit -pcom2 -b19200 -fkisson.tf -d::0 kissinit -pcom4:2e8 -b38400 -fkisson.tf -d::1000 tfpcx -pkiss4:2e8:5 -pkiss2 -b38400:19200 -dm -ftfpcx.ini gp286 tfpcx -u kissinit -pcom2 -b19200 -k -d::0 kissinit -pcom4:2e8 -b38400 -k -d::0 Das Programm KISSINIT ist ebenso wie TFPCX von DG0FT. In KISSON.TF steht der Befehl für den TNC, um auf KISS-Mode umzuschalten, bei The Firmware z.B.: ^X\e@K (ist an den verwendeten Packet-Controller anzupassen)." Unter SP und Turbo-Packet lassen sich laut DG1KDD zwei TNCs an einer seriellen Schnittstelle betreiben. In dem Zusammenhang, wie er den Text wiedergab, läßt sich vermuten, daß dies auch für den Betrieb mit GP zutrifft. Der Text ist über 6000 Bytes lang. Ich spiele ihn bei Bedarf nochmals ein, allerdings sollte er in Mailboxen mit vernünftig gesetzter Lifetime noch zu finden sein. Eine weitere Lösung stammt von OM Robert, DL1MBW. Seine Erfahrungen sind folgende: DL1MBW > GP 23.10.94 12:51 @EU "[...] a) Version GP 1.61 geht mit TFPCX, V. 2.00 konfiguriert auf com1 und com2 zusammen mit zwei Mini- Modems (PC-COM-Fabrikat) und zwei TRX auf zwei verschie- denen Frequenzen. TFPCX-Befehl: "TFPCX -pcom1 -pcom2" Erforderlich ist hierzu der Eintrag in der CONFIG.GP "Multiport=ON" (ohne " ") und evtl. das Ausserkraft- setzen der Schnittstellen-Info in der CONFIG.GP (z.B. durch das Voranstellen eines Semikolons ";") und die entsprechende Einrichtung der NAMES.GP mit der jeweiligen QRG-Angabe/Port-Zuordnung. Beispiel: PORT0 = DB0ABC, 430.333 PORT1 = OE7XYZ, 144.600 D>DB0ABC Einstiegsdigi 70; B>DB0ABC-8 Meine Mailbox; D>DB0ABC B>DB0ABC-8 ... ... D>OE7XYZ Einstiegsdigi 2m; D>S55QRO LINK inn Sueden; D>OE7XYZ D>S55QRO ... ... Beispiel-Ende. Nachteilig ist, dass fuer die Maus aufgrund der Benutzung beider Schnittstellen fuer die TNC nun kein externer Anschluss mehr frei ist, Es sei denn man hat eine "BUS- Maus" mit einer Einsteckplatine in den Rechner, die geht dann zusaetzlich. Es gibt auch Schnittstellenkarten mit Busmaus und zwei Schnittstellen (sehr elegant). Beim praktischen Betrieb sieht man im Monitor (verschach- telt) alle Meldungen beider DIGI und man kann auch ueber beide gleichzeitig connected werden als auch aktiv connec- ten (natuerlich ueber separate Kanõle). Die Kanaele kann man nun auch noch mit spezifischen SSID versehen (z.B. obere Reihe -2 und untere Reihe -7). Einen Durchconnect (cross-Band) einzuprogrammieren waere evtl. etwas fuer die naechste GP-Generation. Dies kann man nanuell machen oder es gleich in der CONFIG.GP vorsehen ("MYCALL=DB3XYA,DB3XYA-7,DB3XYA-7,DB3XYA-7,DB3XYA-7, DB3XYA-2,DB3XYA-2,DB3XYA-2,DB3XYA-2,DB3XYA-2") Beim manuellen Setzen des MYCALL pro Kanal muss dann noch die QRG-Angabe gemacht werden (Eingabe mit ALT-Q) um den Kanal dem gewuenschten Port zu zuordnen. b) Ob dasselbe geht auch mit zwei TNC2-s von DK9SJ geht, kann ich fuer GP nicht sagen, wohl aber funktionierts mit SP, V. 7.00. Obs mit anderen, frueheren Versionen auch geht, waere mal auszuprobie- ren. Bei SP V. 7 ist sogar ein "Durchconnecten" ("Cross-Connect") von einer QRG auf die andere oder ein schrittweises weiter- connecten auf derselben QRG moeglich. [...]" 5. GP und BayCom-Modem Q: Wie kann ich mit einem BayCom-Modem und GP in PR QRV werden? A: Für den Betrieb mit dem BayCom-Modem ist ein Softwaretreiber erforderlich, der die Arbeit des TNC übernimmt. Diese Aufgabe erfüllt TFPCX 2.10 von OM Rene, DG0FT, ebenso wie TFX 2.7 von OM Andreas, DB7KG. Das schon etwas betagte TFPCR kann ebenfalls dafür verwandt werden. Zur Benutzung mit GP muß lediglich eines dieser Programme mit dem entsprechenden Parametern gestartet werden, bevor GP gestartet wird. Anschließend sollte es wieder aus dem Speicher entfernt werden. Ein Batchfile eignet sich für diesen Zweck ideal. Gegenüber anderen Terminalprogrammen, bei denen Software-TNCs durch Eintrag von COM-Port 5 in die entsprechende Konfigurationsdatei angemeldet werden müssen, ist dies bei GP nicht notwendig. GP erkennt automatisch einen evtl. im Speicher befindlichen Treiber. 6. User-Paßworte bei BayCom-Mailboxen Q: In BayCom-Mailboxen besteht die Möglichkeit, sich ein User-Paßwort zu generieren, um sich vor Mißbrauch zu schützen. Leider habe ich bei GP bisher noch keine Möglichkeit gefunden, die entsprechenden Antworten auf eine solche Paßwortabfrage zu automatisieren. Ist dies möglich und, wenn ja, wie? A: Es existieren folgende Möglichkeiten, das Verfahren mehr oder weniger automatisch ablaufen zu lassen: 1. Vor dem Einstellen des Paßwortes in der Mailbox eingeben: "A PWL 1". Dadurch wartet die Mailbox beim nächsten Login mit der Paßwortabfrage solange, bis eine Zeile beliebigen Inhalts abgesandt wird. Danach wird das Paßwort eingestellt. Ebenso wird es in den GP-Editor eingegeben und unter dem Namen ".gpw" abgespeichert. Nun wird die Mailbox in der NAMES.GP mit dem Bezeichner "N>" (TheNet- Node, BayCom-Node u.ä.) eingetragen (nicht Typ "B>", da sonst nicht das TheNetNode-Paßwortverfahren angewandt wird). Nach dem nächsten Connect mit der Mailbox wird zunächst "PW" oder "SY" eingegeben, um GP "scharfzumachen". Es folgt der Paßwortprompt der Mailbox. Mit STRG-O läßt sich die entsprechende Antwort jetzt in das Vorschreibefenster holen. Durch RETURN wird es an die Mailbox gesandt. 2. Außerdem gibt es die Möglichkeit, eines der beiden GPRI-Remote-Programme mit ESC und anschließendem "//PW " bzw. "//PWD" zu starten (, ..., sind die Zahlen, die beim Paßwortprompt abgefragt werden). PW wurde von OM Patrick, DF3VI, geschrieben und ist, wenn es in den Mailboxen nicht mehr zu finden ist, beim Autor zu haben. Das Programm wird nach dem Paßwortprompt aufgerufen. PWD stammt von OM Volker, DG8NBN, und ist auch bei diesem erhältlich. Es wird vor dem Paßwortprompt aufgerufen und kreiert die entsprechende Antwort dann selbsttätig. 7. Darstellung von Packets auf dem Monitor Q: Leider werden bei mir unter GP im Monitorfenster nicht alle Packets dar- gestellt. So kommt es vor, daß einige Frames, die von mir ausgesandt werden, nicht auf dem Monitor erscheinen. Wie läßt sich dem abhelfen? A: Dieser Fehler kann bei Verwendung von TFPCX zusammen mit GP auftreten. Die Ursache liegt in der Default-Einstellung der Monitorparameter in der CONFIG.GP. Der TNC bzw. der entsprechende Softwaretreiber bekommt von GP den folgenden Befehl: "M IUS". Damit aber alle Packets dargestellt werden, muß der Befehl lauten: "M IUSC". Bessert man die entsprechende "TNCINI="- Zeile in der CONFIG.GP aus, funktioniert es problemlos. (TFPCX scheint wohl das Neuhochdeutsche zu bevorzugen und hätte deshalb gern "MUSIC" statt "MUSI" ;-)) 8. GP/2 mit Software-TNC Q: Kann auch die OS/2-Variante von GP - GP/2 - mit TFPCX oder anderen TNC- Emulationen in Verbindung mit einem BayCom-Modem (oder kompatiblen) betrieben werden? A: Nein. Aufgrund der Multitasking-Umgebung, bei der jedem laufenden Programm nur eine bestimmte Prozessorzeit zugebilligt wird, kann OS/2 den Software- treiber nicht ständig abfragen, wie dies von TFPCX etc. verlangt wird. Eine um etliches genauere Antwort liegt vom "Meister" selbst vor: DH1DAE > GP 19.12.94 10:01 23 Lines 1079 Bytes #243 DB0GV@DL "[...] TFPCX läuft in einer DOS-Session unter OS/2 je nach Rechner entweder gar nicht oder so schlecht, daß ein sinnvoller Betrieb nicht möglich ist. Darüberhinaus wäre GP/2 auch gar nicht in der Lage, auf das TFPCX-Interface zuzugreifen, da beide Programme in unterschiedlichen Sessions ablaufen. Da unter OS/2 aber jede Session vollständig gekapselt abläuft und somit durch den Zugriff von anderen Sessions geschützt ist (was ja auch gut so ist, denn dadurch kann eine Amok-laufende Session keinen allgemeinen Schaden anrichten), kann GP/2 also nicht direkt auf TFPCX zugreifen. Die einzige Möglichkeit, ein BayCom-Modem unter OS/2 zu betreiben, wäre ein richtiger OS/2-Treiber, der beim Systemstart geladen wird und dem gesamten System einen virtuellen TNC zur Verfügung stellt. So einen Treiber gibt es aber leider noch nicht. Leider fehlt mir auch wirklich die Zeit für _noch_ ein Softwareprojekt, sonst hätte ich mich schon längst mal an die Arbeit gemacht..." ============================================================================== Die zitierten Textausschnitte wurden im Laufe der letzten zwölf Monate im PR-Mailboxnetz veröffentlicht, waren daher offen zugänglich. Da keine Copyright-Vermerke vorhanden waren, habe ich sie übernommen. Das FAQ darf ganz oder teilweise weiterverbreitet werden, sofern der Urheber genannt wird. Sollten Ergänzungen oder Verbesserungen bei mir eintreffen, werde ich diese in der nächsten Veröffentlichung berücksichtigen. Vy 73 de Sebastian DL9NEC @DB0SIF.#HES.DEU.EU ------------------------------------------------------------------------------- ich habe bisher zwei Zuschriften auf das GP.FAQ erhalten, die ich in dieser Ergänzung berücksichtigen möchte: Zu 3. Probleme mit Logitech-Maus: Ein OM hat den betreffenden Treiber der Version 6.3 bereits mit TFX 2.7 getestet und festgestellt, daß die Probleme hier nicht auftraten. Es scheint also an Interruptkonflikten des Treibers mit TFPCX zu liegen. Dank an OM Michael, DG1GMY, für diese Ergänzung. Zu 5. GP und BayCom-Modem: Die Angabe, TFPCR eigne sich ebenfalls für die Benutzung mit dem BayCom- Modem, stimmt so nicht. TFPCR ist vielmehr ein Programm, um einen TNC, ein KAM oder ähnliche Geräte im KISS-Modus zu betreiben. TFPCR könnte daher möglicherweise eher dazu dienen, GP mit mehr als einem TNC gleichzeitig zu betreiben (vgl. Punkt 4 im FAQ). Es wurde von OM Sigi, DK4NB ex-DL1MEN, geschrieben und ist primär für den Einsatz unter SP gedacht. Das ist, was ich in der Dokumentation zu TFPCR dazu gefunden habe. Dank an OM Florian, DL4NEC, für diesen Hinweis. Weitere Ergänzungen sind erwünscht! Vy 73 de Sebastian DL9NEC @DB0SIF.#HES.DEU.EU