VERON A63
Friese Wouden
____________

VERON afdeling Friese Wouden
Afdelingsblad 'CQ Friese Wouden'

uit de BBS

Velen onder ons zullen voor hun Packet-loopbaan op spraak hebben gezeten en velen zullen dan ook wel de kreet 'Je mot eerst de mike indrukken en dan lullen..' wel kennen. Een voorbeeld:

Station A: "Wie ben jij dan?..."
Station B: "ander....."
Station A: "He?......."
Station B: "ANDER!...."
Station A: "Je mot eerst de mike indrukken en dan lullen, niet tegelijk.."
Station B: "...SANDER!"
Station A: "Da's beter... blablablablablabla..."

Wat hier gebeurt is vrij eenvoudig, persoon B drukt de mike in, en zegt tegelijkertijd zijn naam, maar zijn setje heeft even tijd nodig om over te schakelen van ontvangen - zenden, en precies tijdens dat overschakelen had persoon B de eerste letter van zijn naam al gezegd, en die wordt dus niet uitgezonden. Een eenvoudige oplossing is nu gewoon de mike indrukken, en wat later beginnen te praten.

Ditzelfde probleem doet zich voor met Packet-Radio. Zou het modem wat informatie te verzenden hebben en dat gelijk de lucht in willen sturen, moet het altijd rekening houden met de vertraging van je set. Een voorbeeld:

D ===============
C --------------------------------------------------
B =================================
A --------------------------------------------------------------------------
B =================================
C ---------------------------------------------------
D ===============

De middelste lijn (A) is het modem dat met 'zenden' begint. De set volgt zo snel mogelijk, en zal dus gaan zenden (B). Het modulatie-gedeelte schakelt nog iets later in (C), en als dan alles werkt, kan de data (tekst) de lucht in. Maar wat doen we nu om punt A tot C te overbruggen? Alle informatie die in die tijd zou worden verstuurd wordt namelijk niet door je setje de lucht in gestuurd en gaat dus verloren. Hiervoor dient dus de TX-Delay. De TX-Delay is een waarde die gedurende die tijd alleen maar 010101010101 (zegmaar weggooi-data) verstuurt om de set de tijd te geven om om te schakelen, daarna komt pas de 'echte' informatie. Niet alle setjes zijn even snel (of traag), dus de TX-Delay verschilt per setje. Ik heb hier zelf een Maxon MX-1000 (op 27 MHz Re.d) waarbij ik de TX-Delay rustig op 0,25 kan zetten.

Jawel, 0,25 seconde en het werkt prima. Wanneer je de MX-1000 een klein beetje modificeert (met dank aan TB1KWZ voor de modificatie) kun je zelfs met een TX-Delay van 8 prima uit de voeten. Jawel, 0,08 seconde en het werkt prima.

Een aantal uitzonderingen daar gelaten..: Een aantal stations hier in de buurt (ik noem geen namen; ik wil ze te vriend houden hi) konden vroeger maar geen verbinding met me krijgen. Hoe kwam dat? Zij zaten in die tijd met de squelch van hun set dicht te werken, ipv met een software- of hardware-DCD in het modem. Wat gebeurt er dan?..... Mijn modem wil zenden (A), mijn set volgt (B), de modulatie is ook ingeschakeld (C), maar nu komt het verschil naar voren! Zij zitten met een set die een 'trage' squelch heeft, en bij hen springt de squelch pas open op punt (D), maar dan is mijn tekst er al gedeeltelijk doorheen. Een squelch van een set is namelijk traag, hoe je je set ook modificeert of hoe snel jouw squelch ook is, het werkt altijd vertragend. Het heeft dus de voorkeur de squelch helemaal open te laten staan.

Misschien zou je zeggen, dan zet je je TX-Delay toch flink hoger voor die stations? Er zijn twee redenen naar voren te brengen waarom dat niet echt de beste oplossing is. Een ervan zal ik naar voren brengen bij de uitleg van de SLOTTIME (aangeduid met de letter W), en de andere zal ik hier proberen duidelijk te maken. Er zijn stations die hebben om deze reden de TX-Delay maximaal ingesteld. Na wat proberen blijkt dat bij een WA8DED eprom (TFPCX ook) de TX-Delay maximaal op 127 kan worden ingesteld, dus gebruiken sommigen dan ook.

We rekenen voor het gemak even met een TX-Delay van 1,5 seconde. 1,5 seconde, wat maakt dat nu uit? Vrij veel lijkt me. 2 stations met een TX-Delay van 1,5 seconde zijn druk met elkaar aan het typen. Ze roepen beide ongeveer 10 keer per minuut... = 2 x 10 x 1,5s. = een halve minuut van die 'weggooi-data' op het kanaal per minuut! De helft van de tijd wordt dus gevuld met "weggooi-data", en dat is niet zo handig als je je realiseert dat 1200 Baud toch al niet zo snel gaat. Een tijd-schema erbij:

0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1,0 1,1 1,2 1,3 1,4 1,5(s)
======================================
A      B  C   D
       SABM+

A = modem wil zenden,
B = set gaat zenden,
C = set is op vermogen + modulatie werkt,
D = squelch tegenstation springt open.

Stel dat je 1 seconde aan tekst wilt verzenden... dat zou dan ongeveer worden:
1.0s <<tekst>> / (1.0s <<tekst>> + 1.5s <<TX-Delay>>) = 40% effectief, maar
1.0s <<tekst>> / (1.0s <<tekst>> + 0,4s <<TX-Delay>>) = 71% effectief!

200 Baud is niet snel, maar met 40% effectief werken kom je dan uit op zo'n 480 Baud, en met 71% toch al weer op zo'n 850 Baud!

Dit is natuurlijk lekker vaag en theoretisch gebabbel, en in de praktijk zijn er nog veel meer factoren van belang, maar het blijft natuurlijk gewoon nodig om de frequentie zo effectief mogelijk te gebruiken, en alle kleine beetjes schelen uiteindelijk dan toch weer een heleboel. (reken maar uit hoe vaak je begint te zenden per minuut, en hoe vaak die TX- Delay dus gebruikt wordt)

Realiseer je dus dat je TX-Delay alleen hoort te gebruiken om de tijd dat je set nog niet aan het zenden is ("deadtime" genoemd) te overbruggen. Als je set 0,20 seconde nodig heeft om om te schakelen is een TX-Delay van 0,25 seconde dus al ruim voldoende. Deze "deadtime" speelt vooral een rol bij de bepaling van de slottime. Een andere reden voor een zo kort mogelijke TX-Delay is de volgende. Stel dat dit de situatie is:        Station A BBS jij.

Jij hoort station A niet, en station A hoort jou niet. Wanneer je nu iets naar het BBS wilt zenden kun je maar beter zodra je aan het zenden bent zo snel mogelijk je informatie oversturen zodat het BBS het binnen heeft, dan dat je eerst 0,60s TX-Delay hebt. In 0,60s is de kans namelijk zeer groot dat station A ook begonnen is met zenden drukt hij jou van de band af.

Een mooie waarde voor de meeste setjes is een TX-Delay van 0,3 tot 0,5 seconde. Vroeger zat ik hier met een Pan MegaTop, en de TX-Delay kon ook bij deze set makkelijk op 0,25 seconde staan, als mijn tegenstation de squelch maar open had staan. Stond de squelch dicht, moest ik 'm weer op 0,4 seconde zetten. Maar een TX-Delay van 0,7 tot 1,5 seconde is pure kanaalvervuiling en hoogst irritant, omdat een ander op dat moment niet kan zenden. Sommige setjes kun je eenvoudig modificeren en dan is het geen enkel probleem om met een TX-Delay van 0,1 tot 0,15 seconde te werken.

Houd hem dus zo rond de 0,3 tot 0,5 seconde... Stations die met een TX-Delay van rond de 1,5 seconde werken herken je aan een IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIkrrrt-modulatie, terwijl dit dus een IIIIIkrrrt-modulatie zou moeten zijn. Hmm..beetje vaag....nou ja jullie begrijpen me wel denk ik.

De TX-Delay is in de meeste programma's in te stellen als parameter 'T'. Bij SP v7.00 en hoger moet je even in je config.sp de parameter 'TXD' meeveranderen. Als je G8BPQ gebruikt moet je in de BPQCFG.TXT zijn om het te veranderen, en wel in de PORTS definitie. Let op, je moet daar instellen hoe lang de TX-Delay duurt in ms. (Bijv. TXDELAY = 350) Mocht je nu tot de conclusie komen dat je niemand meer kan connecten zodra je de TX-Delay onder de 0,40s zet, is je set eigenlijk te traag voor het gebruik op packet (een veel te grote "dead time"). Ik raad je dan aan om een andere packetset te gaan gebruiken. (het argument "het heeft altijd goed gelopen ik heb nooit klachten gehad" is natuurlijk te gemakkelijk he...).

In een artikel over de SLOTTIME zal zeker duidelijk worden waarom!