DE PARAMETERS BIJ PACKET RADIO DOOR PA0WQ.

Zo, eindelijk! Na heel wat zweet en tranen is je packet-spulletje klaar en het eerste connect is zowaar gelukt! Maar werkt alles nu ook wel optimaal? Je weet wel, dat er veel dingen kunnen worden ingesteld, zoals de drempel van de squelch in het modem en van de DCD ('Data Carrier Detect') of de verschillende parameters, zoals de Txdelay, de Persistance en de Slottime, maar die had je in eerste instantie maar even gelaten voor wat ze waren.

Zeker met de huidige zware belasting van onze packetkanalen is het echter wel belangrijk deze zaken nog eens nader onder de loep te nemen. Je wilt toch wel heel erg graag weten, of je 'performance' optimaal is en of je door een verkeerde instelling niet ongemerkt asociaal gedraagt en dus anderen hindert, nietwaar? Om die parameters optimaal te kunnen instellen is het wel belangrijk om wat inzicht te hebben in hun functie.

Laten we maar eens nagaan, wat er al zo tijdens een packetcontact gebeurt.

Stel dat wij met een meertal stations ingelogd zijn op PI8ZAA; een heel normale situatie dus. We beginnen met kijken op het moment dat PI8ZAA net zijn datastroom naar een

van de stations heeft beeindigd; het kanaal is dus even vrij. Alle ingelogde stations constateren tegelijk dat de draaggolf van PI8ZAA is weggevallen, hun DCD (Data Carrier Detect) signaal is namelijk naar 0 gegaan. Nu willen alle stations meteen hun eigen pakketjes kwijt en zouden zich tegelijk in het opengevallen gat willen storten. Maar als er meer dan een station tegelijk op het kanaal in de lucht zou komen krijgen we een botsing ("collision") van packets en dan gaat alles fout.....

Daarom wordt eerst bij elk deelnemend station met een bepaalde waarschijnlijkheid bepaald, of hij wel of niet zal gaan zenden. Dat gebeurt door het random (willekeurig) kiezen uit een vast ingesteld aantal mogelijkheden.

Die waarschijnlijkheid kan worden ingesteld via de parameter PERSISTANCE, waarover hieronder meer.

Maar, direct na het wegvallen van het DCD - signaal is een station nog niet onmiddellijk klaar om te zenden; hij moet misschien eerst nog op frequentie komen (vooral bij PLL gestuurde zenders), een eventueel antennerelais moet worden omgeschakeld, enz.

Hiertoe wordt het station gedurende die geen data-betekenis hebben) en daarna - als er een redelijke zekerheid bestaat dat ook het ontvangende station klaar is - komt de eigenlijke datastroom.

De tijd, die gewacht wordt vanaf het moment van inschakelen van de zender totdat de feitelijke datastroom mag beginnen stellen we in met de parameter TX-DELAY (transmissie-vertraging).

Zodra een signaal op het kanaal aanwezig is, wordt de draaggolf door alle stations op het ontvangen, hun DCD gaat daar weer naar 'on' waardoor hun verder het zwijgen wordt opgelegd tot dat het kanaal weer vrij is.

Mocht een station bij de kansbepaling ditmaal nog niet het sein gekregen hebben te mogen zenden, moet weer een hele slottijd worden gewacht, voordat opnieuw de kans tot zenden mag worden bepaald.

Het is duidelijk, dat een goede werking van het DCD (Data Carrier Detect)

signaal van groot belang is. Is het signaal 'on', dan zal alle actie zijn

geblokkeerd. Bij een slechte werking van de DCD (bij ontvangst van een

draaggolf vaak zichtbaar door een knipperende LED) kan je geen betrouwbare

werking verwachten.

De inschakeldrempel van de DCD is bij de meeste modems met een potmeter in

te stellen. Bij sommige systemen gebruikt men een hardware-, bij anderen een

software-matige instelling.

DE INSTELLINGEN IN DETAIL

DE TXDELAY.

Als die te kort staat ingesteld, zal je zender met de data al beginnen te zenden voordat het ontvangende station gereed is, zodat de eerste data verminkt overkomen. Je zou dan misschien maar meteen overwegen om de TxD maar flink lang te maken, bijvoorbeeld 1000 ms., dan weet je tenminste, dat alle vertragingen in het systeem worden overbrugd.

Die gedachte is niet juist! Als je de TxD langer maakt dan nodig, boek je geen enkele winst meer en introduceer je alleen maar verliestijd. Bedenk dat je pakketlengte vaak niet groter is dan 128 Bytes, terwijl die verliestijd bij elk pakketje moet wordt opgeteld! Je effectieve snelheid gaat dus snel achteruit. Ook moet je niet vergeten, dat je tijdens de TXD zelf 'doof' bent voor alle (stoor-)signalen op het kanaal, dus de kans op verminkingen neemt toe.

Maak dus een connect met een station en ga terug met de instelwaarde van de TXD totdat er fouten in de transmissie optreden en doe er dan iets -zeg 20%- bij, dan zit je optimaal.

Praktische waarden zijn zo 50 - 400 ms., de hoogste waarden bij lage baudrates als 1k2

Bedenk dat bij 9k6 de praktische snelheid van de datastroom zo'n 1000 Bytes per seconde bedraagt.

Een packetlengte van 128 Bytes vraagt dus 1/8 seconde = 125 ms. Stel dat je

TXD 100 ms langer is dan nodig, dan wordt de tijd voor het verzenden van een

pakketje al 225 ms, de snelheid is dus maar 56 % van wat mogelijk is!

Blijkt het echter, dat een verbinding alleen mogelijk is met veel hogere waarden van de TXD, dan is het hoogste tijd om eens de verschillende vertragingen in je eigen installatie (vooral in de ontvanger) aan te pakken en die te verminderen. Vooral bij hogere baudrates breekt je die traagheid op.

Een goede test is om in te loggen op PI1EHV en dan het commando T of Txd te geven en dan even te wachten. Na enkele seconden komt PI1EHV met een lijst van gehoorde stations en de daarbij gemeten TXD. (Alleen bij Net-CHL, onder Linux niet meer mogelijk).

De PERSISTANCE.

Een waarde van 32 is aan te bevelen voor de huidige zwaar bezette kanalen. Dat betekent, dat de waarschijnlijkheid, dat je zender in het open gat springt dan 32 uit de 256 mogelijkheden bedraagt of 32/256 = 1 0p 8.

Bij een zwak bezet kanaal kan je tot 64 gaan (=25% trefkans) Ga je veel lager, dan kom je minder makkelijk aan de beurt; ga je veel hoger, dan neemt de kans op botsingen bij de huidige kanaalbezetting toe, dus verlies van efficiency van je eigen signaal en ook dat van de ander! (Heel ASO)

Vergeet niet, dat na de slottijd van bijv. 100 ms opnieuw de kans wordt bepaald. Per seconde kan je dan al 10 maal een kans hebben gekregen, dus zo veel tijd wordt daarmee niet verspeeld. Wel een heel domme gedachte is om 256 in te vullen. Dan kom je wel veel aan de beurt maar krijg je een vergelijkbare situatie van iemand, die met een blinddoek op in zijn auto de verkeersweg oprijdt!

De SLOTTIME.

Deze tijd moet de inschakelvertraging van de set overbruggen.Veel gebruikte waarden: 50 tot 150 ms. Bij te kleine waarde van de slottijd komt de zender niet of niet op tijd in.

Als er grotere waarden nodig blijken, verdient ook hier het aanbeveling om eens serieus de (te) grote vertragingen in de installatie te lijf te gaan en die allereerst te reduceren alvorens verder te gaan!

Maar WAAR moeten we nu al die waarden instellen?

Dat is helaas niet standaard voor te schrijven, daar het afhankelijk is van het gebruikte systeem van hard- en software. Meestal moet je dat doen in de configuratie-bestanden als CONFIG.NET of AUTOEXEC.NET. Je zult daarvoor dus eerst de documentatie moeten inkijken.

PING

Tenslotte biedt o.a. PI1EHV ons nog een heel handige controlemogelijkheid. Geef je bijvoorbeeld het commando PING PI1EHV 5 128, dan zal je zender elke 5 seconden inkomen om een burst van 128 Bytes uit te zenden. Als je dan na enige tijd het commando PING (of PI) geeft, dan zal je op je scherm zien verschijnen iets als:

Host Sent Rcvd % Avg RTT interval length ID

44.137.24.40 30 23 76 5349 5 128 1

Dat betekent:

Onder Host: je IP nummer

Onder Sent: het aantal verzonden pakketten

Onder Rcvd: het aantal correct ontvangen responses

Onder % : het percentage correcte responses

Onder Avg RTT: de gemiddelde return tijd van het pad

Onder interval: de door jezelf ingestelde interval in sec.

Onder length : de door jezelf ingestelde pakketlengte in Bytes

Onder ID : een identificatiegetal

Met PING CLEAR stop je het proces (let wel: je belast het kanaal wel met je

meting, dus laat het niet een etmaal doorlopen......

Voor het bovenstaande is echter wel nodig, dat je over een IP-nummer beschikt, dat door PI1EHV kan worden erkend, en dat je ergens in je configuratie de route naar PI1EHV hebt vastgelegd in Routes.net als Route Add PI1EHV 4k8 (als 4k8 de aanduiding is van je modem). Let wel! Dit gaat alleen op voor de snelheid van 4k8.

Luut, PA0WQ

---