| |
DG4FDI > NETROM 05.11.03 16:58l 149 Lines 5672 Bytes #999 (0) @ DL
BID : 5BDDB0ROF00D
Read: DG8NGN OE3KLU GUEST
Subj: Re: Problem mit DAMA
Path: DB0FHN<DB0FOR<DB0SIF<DB0CWS<DB0ROF
Sent: 031105/1455z @:DB0ROF.#HES.DEU.EU [Rotenburg/Fulda, JO4] obcm1.04beta46
From: DG4FDI @ DB0ROF.#HES.DEU.EU (Thomas)
To: NETROM @ DL
X-Info: Sent with login password
X-Info: Received by SMTP-gateway
Hallo
Rup, DJ6HH schrieb in NETROM@DL
> Hi, Netrom-Kenner;
> seit der Umstellung meines Boxcalls auf DA5UHA und dem Zugang bei DB0HHB, der
> ansonsten ganz hervorragend klappt, kommt es zu folgendem Problem:
> Einer meiner Partner ist DK0MNL. Es ist eine der wenigen Stationen, die mich
> aktiv rufen.
> Das geht soweit klar, dass meine Box die Connectmeldung sendet - danach kommt
> eine Warnung vom DAMA-Master bei DB0HHB, und kurz darauf der Disconnect.
>
> Meine Hardware hier ist ein PTC-PRO, und auf dem UHF-Port ist das darin
> verbaute FSK-Modem aktiv. Laut Hersteller ist der SCS-PTC voll DAMA-faehig.
> Das Problem ist in vielen Jahren der Nutzung bisher nie aufgetreten.
>
> Ich haenge mal eine Mitschrift aus dem Monitor an, aus der ich die Zeilen
> herausnehme, die nicht den Verkehr DK0MNL<>DA5UHA betreffen.
>
> Ich habe hier auch mit sehr langen Frackwerten (12 Sek.) probiert, es aendert
> nichts an der Fehlermeldung.
>
> Hier der Mitschnitt von heute nachmittag (UTC):
>
>
> [3] fm DK0MNL-11 to DA5UHA via DB0HHB* ctl SABM+
> [3] fm DA5UHA to DK0MNL-11 via DB0HHB ctl UA- pid 04
> [3] fm DA5UHA to DK0MNL-11 via DB0HHB ctl I00+ pid F0 (230)
> [FBB-7.00i-AB1FHMR$]
> Pactor-Packet-Link BBS DA5UHA in Hamburg. KEIN Internet-Forward, bitte!
> WFBB Port 3.
> Ch. 2 (PACK-9600) : DK0MNL-11 - Die 04/11/03 16:30
> via : DB0HHB-0
>
> QTC: 0 Mail(s) / Bul(s) = 0 Kb.
>
> (1) DK0MNL de DA5UH
DA5UAH sendet nach dem UA schon mit I00+.
+ steht fuer Poll/Final-Bit, was bedeutet :
"nach diesem Frame kommt kein Weiteres, Gegenstation bitte sofort antworten,
ohne Persistance/Slottime-Algorithmus bzw Resptime abzuwarten".
Bei DAMA darf nur der Master (DB0HHB) mit Poll senden, nicht aber der
Slave (DA5UHA).
Vermutlicht hat DA5UHAs Firmware nicht mitbekommen, dass es sich
um einen DAMA-QSO handelt.
Leider zeigt dieser mit FBB erstellte Mitschnitt kein DAMA an.
Mans muesste mit einem anderen Hostmode-Programm mitschneiden.
> [3] fm DK0MNL-11 to DA5UHA via DB0HHB* ctl RR1-
> [3] fm DK0MNL-11 to DA5UHA via DB0HHB* ctl I10+ pid F0 (79)
>
> *** from DAMA-Master DB0HHB> WARNING: non-DAMA Poll #1, Disconnect after 3 !!
DB0HHB mischt sich mit Text in eine laufendes QSO ein.
Das darf m.E. nicht sein, wenn das QSO transparent bleiben sollte.
> [3] fm DA5UHA to DK0MNL-11 via DB0HHB ctl RR1- pid 04
> [3] fm DA5UHA to DK0MNL-11 via DB0HHB ctl I11^ pid F0 (8)
> A BBS >
Jetzt macht es die SCS-Firmware richtig, hier kommt kein Poll-Bit
mit dem Info-Frame. Jetzt scheint sie DAMA mitbekommen zu haben.
> [3] fm DK0MNL-11 to DA5UHA via DB0HHB* ctl RR2+
> [3] fm DA5UHA to DK0MNL-11 via DB0HHB ctl RR1- pid 04
> [3] fm DA5UHA to DK0MNL-11 via DB0HHB ctl I12^ pid F0 (28)
>
> (1) DK0MNL de DA5UHA BBS >
Wieder richtig verhalten.
> [3] fm DK0MNL-11 to DA5UHA via DB0HHB* ctl RR3+
> [3] fm DA5UHA to DK0MNL-11 via DB0HHB ctl RR1- pid 04
> [3] fm DK0MNL-11 to DA5UHA via DB0HHB* ctl DISC+
> [3] fm DA5UHA to DK0MNL-11 via DB0HHB ctl UA- pid 04
DB0HHB sagt "Disconnect nach drei Polls", es war aber nur einer.
Da sich oben DB0HHB eingemischt hat, hatte dieses QSO einen zusaetzlichen
Inhalt, der nicht protokollgrecht f. eine S&F-Verbindung ist.
So gesehen, ging die Trennung in Ordnung.
> Kann einer von Euch raten, wie wir das in den Griff kriegen koennen?
> Liegt es an einer Unvertraeglichkeit von SCS-PTC und TNN (vielleicht haben
> die ja nur mit XNet oder RMNC getestet)?
TNN regiert hier wirklich etwas penibel wegen diesen einem Poll, zumindest
staerker als bei Flexnet oder XNET.
Besser TNN meldet sich wirklich erst bei drei und nicht bei einem Poll.
Machzutragen ist, dass sich beim TNN um
HHB:DB0HHB> TheNetNode (TNC3), Version 1.79pre1 (Oct 7 2002)
; BETA-TEST SOFTWARE, USE ONLY FOR DEBUG PURPOSES.
Copyright by NORD><LINK, free for non-commercial usage.
See www.nordlink.org for further information.
This version compiled for 8 Ports, 40 L2-Links and 50 Circuits.
mit diesen Parametern
HHB:DB0HHB> Parms:
01:NoAckBuf 16 02:L3-MaxTime 3000 03:SaveConfig 6
04:DAMA-Speedf 0 05:DAMA-MaxPri 10 06:DAMA-MaxPol 3
07:DAMA-Tout 50 08:CommandLog 0 09:SysopLog 1
10:TestSSID 15 11:ConvSSID 1 12:AutoIPR 3
13:Min-Quality 40 14:L3-MaxLT 30 15:Infocast 60
16:Broadcast 30 17:Lifetime 30 18:T-Window 10
19:Paclen 236 20:L4-Bsytim 20 21:L4-Retrans 3
22:L4-Acktim 1
handelt.
Auf der anderen Seite ist auch die SCS-Firmware nicht ganz unschuldig.
Ich habe bei Tests mit meinem SCS-PTC-IIpro (Firmware 3.3c) bemerkt,
dass Dieser im Nicht-DAMA-Modus Durchgaenge aus Info-Paketen mit Final-Bit
am letzten I-Frame abschliesst.
Keine andere Firmware od. Knotensoft aus dem Mitteleurop. Raum tut dies.
Es tut not, dieses abschaltbar zu machen, damit ein Persistence-Algorithmus
auf der Gegenseite greifen kann.
Sonst erhaelt man eine "Stossstangensenden" zw. SCS-Firmware-Benutzer
und dessen Gegenstation. Andere Benutzer auf der QRG kommen kaum noch zu Zug,
wenn die SCS-Firmware-Station laengere Einspielungen taetigt.
Es sei denn, es liegt eine Bedigung vor, die IPOLL erlaubt, aber IPOLL
beherscht die SCS-Firmware leider nicht.
Genausowenig wie einen Framesammler, der nun mittlerweile jast jede Firmware
hierzulande hat.
> 73 de Rup
> dj6hh@da5uha.#hh.deu.eu
> Kopie an Sysop DK0MNL und DL1ZAM von SCS.
73 de Thomas
BBS : DG4FDI@DB0ROF.#HES.DEU.EU
SMTP: dg4fdi@db0spp.ampr.org
Remote sysop DK0MNL
Read previous mail | Read next mail
| |
