--------------------------------------------------------------- PACKETRADIO, MEER MOGELIJKHEDEN ALS MEN VERWACHT. ----------------------------------------------------- Dit is op zich heel begrijpelijk als je indenkt dat radio een van de weinige mogelijkheden is om in zo'n dunbevolkt land met elkaar te kunnen communiceren. Voor de zendamateur die tevens de computer als hobby heeft is het een fijne mogelijkheid om datacommunicatie te plegen over de radio. De Nederlander kennende is het namelijk i.p.v. de dure telefoon beter om gebruik te maken van de radio. In eerste instantie werd dat gedaan met baudot. Tevens kan men dan communiceren met telexmachines die over het algemeen op 50 baud werken. Maar waarom communiceren op 50 baud als ons een snelle computer ten dienst staat. Dit gaf aanleiding om voor de computer een andere manier van datacommunicatie te ontwikkelen voor over de radio. In het begin werden daarom expirimenten gedaan met telefoonmodems en werden die gekoppeld met de zendontvangers. Er zitten echter wat nadelen aan om te koppellen zoals bij een telefoonverbinding. Wat is nl het geval, bij een telefoon is er sprake van een duplex verbinding. Als we spreken dan kunnen we elkaar onderbreken en er doorheen praten. Er is nl een zg. antilokaal schakeling in de telefoon, die zorgt dat ons microfoonsignaal onderdrukt wordt t.o.v. wat er van de andere kant komt. Met radio zouden we daarvoor 2 frequenties nodig hebben om zo'n duplex verbinding te kunnen realiseren. De computerverbindingen over de telefoon gebruiken vaak een snelheid van 1200 bps (bits per seconde). Dit is echter sneller als dat de meeste mensen kunnen typen en het is dan ook zonde om een verbinding te laten bestaan om ,voor het grootste deel van de tijd er alleen een carrier over te transporteren. Vooral bij een verbinding over de ether is dit natuurlijk uit den boze. Daarom wordt onze informatie in kleine pakketjes gestopt die dan met 1200 bps wordt uitgezonden, en daarna wacht tot het volgende pakketje gevuld is. De mogelijkheid bestaat dan voor andere stations om hun pakketje uit te zenden op het moment dat onze zender uitgeschakeld is. Zodoende onstaat een timesharing systeem waarbij een ieder op zijn beurt blokken informatie kan uitzenden. Alle stations moeten echter wel een goede timing gebruiken wil het een goed bruikbaar systeem zijn. Deze timing wordt bepaald door de TNC (terminal node controller) welke verantwoordelijk is voor het inschakelen van de zender, het decoderen van de informatie en het assembleren van packet frames. Deze informatie gaat in serieel ascii formaat naar de computer of terminal. Voor sommige computers zoals de commodore 64 is het mogelijk om met een normaal telefoonmodem te werken. De computer heeft dan het ax25 protocol in de software zitten. Bij een tnc zit deze in een Eprom in de tnc en wordt afgehandeld door een microprocessor in de tnc. I--------I naar terminal I I of computer I Timing I I I I I I---I----I I I I-----I-----I I---I----I I---------I I---------I I serial- I I micro- I I HDLC I I I I interface I---------I procc. I-----I control I---I MO-DEM I I I I I I I I I I-----I-----I I---I----I I----I----I I----I----I I I I I I I---I----I I I I I I I I I---------------I Memory I----------I I I I naar set I--------I TX/RX + PTT fig 1. TNC. De serieele interface zorgt ervoor dat we via een rs232 poort kunnen communiceren met de computer. Deze interface zet de data om naar parralel zodat met de memory en de microprocessor data uitgewisseld kan worden. De microprocessor zorgt voor de besturing. De memory bevat de eprom welke de software bevat en een ram buffer waar data wordt opgeslagen. De HDLC controller zorgt echter voor de assemblage van de ax25 frames welke door het modem tot toontjes worden gemaakt die we via de radio kunnen uitzenden. De meest gebruikte tonen zijn volgens de Bell 202 standaard nl. 1200 en 2200 Hz. Deel 2. HET (A)X 25 PROTOCOL: Volgens mij moet de uitvinder van het protocol postbode zijn geweest om dit te kunnen ontwikkelen. Het navolgende verhaal illustreerd dit. Jaap gaat 3 weken met vakantie en spreekt af met het thuisfront dat hij iedere dag een brief zal sturen over wat hij die dag gedaan heeft. Hij spreekt verder af dat wegens de slechte verbinding het thuisfront steeds een bericht zal sturen dat de brief goed aangekomen is. De eerste dag van de eerste week stuurt hij een brief hij zet de datum erop (week 1 dag 1) en stopt hem in een enveloppe, hij schrijft op de enveloppe het adres waar de brief naartoe moet en de afzender. Tenslotte gaat er een postzegel op en gaat de brief op de post. Aangekomen op het postkantoor wordt naar de onderste regel van het adres gekeken en wordt de brief naar Nederland gestuurd. Vandaar gaat hij naar de woonplaats en dan neemt de postbesteller (op de fiets) de brief mee naar de straat en huisnummer die daarop vermeld staan en doet de brief daar in de bus. De brief wordt uit de bus gehaald en overhandigd aan de geadresserde. Die leest tenslotte de brief en stuurt meteen een berichtje terug dat de brief van week 1 dag 1 goed is aangekomen. Dit gaat zo door totdat op de derde dag de postbesteller van z'n fiets wordt gereden en de post in het water beland, de brief komt dus niet aan. De brief van de vierde dag komt echter wel aan. Naar Jaap wordt bericht gestuurd dat de brief van de derde dag niet is aangekomen en dat die van de vierde dag wel is aangekomen. Jaap heeft nog een copietje en besluit om de brief van de derde dag opnieuw te versturen. Dit is tenslotte de enige manier om het thuisfront goed op de hoogte te houden. Deze manier van communiceren lijkt in grote lijnen op die van packet radio. Bij packet radio stoppen we nl onze informatie in kleine pakketjes die bevestigd worden door de geadresseerde. Op het moment dat er een storing of een botsing van het signaal optreed met een ander signaal dan zal dat pakketje opnieuw worden verstuurd. Hieronder treffen we aan hoe zo'n pakket is opgebouwd. ----------------------------------------------------------------- I FLAG I ADDRESS I CONTROL I PID I INFO I FCS I FLAG I I==========I=========I=========I======I=======I======I==========I I 01111110 I 112/560 I 8 I 8 I n x 8 I 16 I 01111110 I I I bits I bits I bits I bits I bits I I I----------I---------I---------I------I-------I------I----------I I Synchro- I calls + I type Iproto-I data Icheck-I Synchro- I I nisatie I ssid I frame I col I I sum I nisatie I ----------------------------------------------------------------- fig 2. ax25 frame Overigens spreken we hierbij van en HDLC (High Level Data Link Control) Frame. Een pakket bestaat vaak uit meerdere frames tegelijk. Het FLAG field ziet er altijd hetzelfde uit nl. 01111110 en dient voor synchronisatie. Het ADDRESS field bevat de callsigns. En dat zijn die van het eigen station, die van het eindstation en de eventuele digipeaters die gebruikt worden. De SSID is een zogenaamde secondary station indentifier waarmee een station onderscheid kan maken tussen de verschillende toepassingen die het station kent. De ssid is altijd een nummer tussen 0 en 15. Ook zit in het address field een zg. H bit wat bij digipeatergebruik na iedere digipeater van status zal veranderen. Dus bv. bij het eerste station 0 bij het 2e 1 . Overigens is het maximale aantal digipeaters 7. Het CONTROL field wordt gebruikt voor besturing van het x25 protocol, het identificeert het gehele frame. Het bovenstaand geillustreerde frame is in dit geval een I (INFO) of een UI (Unnumbered Info) frame, dit zal dan ook door dit control field worden aangegeven Tevens zal bij I frames hier het frame een nummer krijgen. Het I en UI frame zijn overigens de enige type frames die het PID en INFO blok in zich hebben. De overige frames bezitten deze 2 blokken niet. Die worden zg Supervisory frames genoemd en dienen niet voor informatieoverdracht maar voor de besturing. Aan de hand van een praktijkvoorbeeld zal ik de werking wat nader verklaren: pa0aaa maakt verbinding met pa0bbb. In het adresveld staat dan pa0bbb0 pa0aaa0, de nul staat hier voor ssid 0. Het control field definieert de connect request en dit is daarom een SABM (set asynchronous balanced mode) frame, waardoor de timers in de tnc's gesynchroniseerd worden. Het PID byte geeft aan dat het infoveld ascii bevat en geen ander protocol, hier kom ik later op terug. Het infoveld is leeg bij de supervisory frames. Tenslotte geeft het fcs veld altijd de checksum aan van het gehele frame die bij de ontvanger ook weer berekend wordt en vergeleken met die die ontvangen is. Zodoende is verminking uitgesloten en komt de data goed aan. Pa0bbb antwoord met een UA frame (Unnumbered Acknowledge) als acceptatie en antwoord op de ontvangst van het sabm frame. Nu zijn beide stations met elkaar geconnect en begint bv pa0aaa met het intikken van tekst. Deze tekst komt in het dataveld van een I frame terecht, het eerste I frame heeft nummer nul wat tevens in het control veld wordt aangegeven. Tenslotte volgt de data. Deze is maximaal 256 bytes per frame maar wordt in de meeste gevallen d.m.v. een commando aan de tnc ingekort tot 128 bytes per frame. Als de data de 128 bytes overschreid dan wordt de frame uitgezonden. Ook wordt de data uitgezonden op het moment dat er een return gegeven wordt. Pa0bbb antwoord pa0aaa met RR 1 (Receiver Ready) ten teken dat hij info frame 0 goed heeft ontvangen en klaar is voor ontvangst van frame nummer 1. Als de waarde in het FCS veld niet overeenkomt met de berekende waarde dan is de data niet goed overgekomen. Er wordt dan geantwoord met een REJ (reject) frame. Hierdoor zal het tegenstation het laatst verzonden frame herhalen. Als er fouten in het protocol voorkomen dan wordt geantwoord met een FRMR (Frame Reject) frame. Dit kan oa. onstaan als de nummering van de frames niet klopt, of als het frame bv een adresveld bevat groter dan 560 bits. Het frame voldoet dan niet aan de regels van het protocol en een FRMR is dan het gevolg. Aan het einde van de verbinding verbreekt men de connect door een DISC (disconnect) frame te versturen. Dit wordt dan op zijn beurt beantwoord met een DM (Disconnect Mode) frame ten teken dat er succesvol is gedisconneceen SABM (set asynchronous balanced mode) frame, waardoor de timers in de tnc's gesynchroniseerd worden. Het PID byte geeft aan dat het infoveld ascii bevat en geen ander protocol, hier kom ik later op terug. Het infoveld is leeg bij de supervisory frames.ere informatie die meerdere gebruikers kunnen lezen. Ook worden deze UI frames wel gebruikt bij protocollen zoals TCP/IP waarbij alle informatie en de besturing zich in het informatieveld bevind. Als de buffer van de tnc even vol zit en geen nieuwe frames meer kan acepteren dan dan dit station antwoorden met RNR (receiver not ready) frames. Dit als teken dat even geen frames ontvangen kunnen worden. Als dit wel weer mogelijk is dan zal dit station weer RR frames gaan uitzenden. Het bovenstaande is echter een voorbeeld van het ax25v1 protocol. We kennen echter ook het ax25v2 protocol. Bij dit protocol wordt tevens in ieder I frame niet alleen het nummer van dat betreffende frame aangegeven maar ook het nummer die men zelf het laatst heeft ontvangen. Deze nummers heten NS (number send) en NR (number received). Dit protocol test ook uit of we niet achter liggen, hiervoor wordt een zg. poll/final bit gebruikt wat zich tevens in het control veld bevind. Als bevestiging op een I frame komt dan normaal ook een RR/F (nr) (receiver ready final). Als het station verwacht dat er nieuwe data is verzonden dan wordt het tegenstation ondervraagd met RR/P (nr) (receiver ready poll nr). Hierdoor wordt regelmatig aan het tegenstation gevraagd of het nog meer data te versturen heeft. Vervolg deel 3 HET WERKEN VIA TUSSENSTATIONS: Met packet radio is het mogelijk om via een of meerde tussenstations een verbinding op te bouwen naar het eindstation. Een methode veel toegepast is via een DIGIPEATER. Ieder packet station is als digipeatetocol en een FRMR is dan het gevolg. Aan het einde van de verbinding verbreekt men de connect door een DISC (disconnect) frame te versturen. Dit wordt dan op zijn beurt beantwoord met een DM (Disconnect Mode) frame ten teken dat er succesvol is gedisconnecat bij het ssid van dat station een zg H bit wat wordt omgeschakeld van 0 naar 1. Bij het uitzenden van de packet door de digipeater zal dus het gehele packet met uitzondering van het H bit hetzelfde worden uitgezonden. Mocht dan bv door condities toch eens een keer het frame van het eerste station bv door condities direct bij het laatste station worden ontvangen dan wacht dit laatste station toch totdat het via de digipeater is binnengekomen. Dit om botsingen van signalen te voorkomen. Bij digipeater gebruik spreken we van zg end to end acknowledgment. D.w.z. dat een packet over de gehele route wordt uitgezonden voordat een RR (acknowlegment) van de eindstation over de gehele route terug komt. I--------I 1 (1) I--------I 2 (3) I--------I 3 (5) I---------I I I-------I I-------I I-------I I I A I I B I I C I I D I I I-------I I-------I I-------I I I--------I 6 (2) I--------I 5 (4) I--------I 4 (6) I---------I fig. 3 Werken via tussenstations A,B,C en D zijn stations. B en C vervullen beiden een digipeater functie. De getallen vormen de volgorde voor waarin de packets worden uitgezonden, de getallen tussen haakjes laten we even buiten beschouwing. We stellen voor dat bij stap 1 informatie wordt overgedragen in een I frame van A naar B. Station B zendt deze als stap 2 uit (met het H bit op 1) naar station C, deze zendt dit met (met zijn h bit op 1) naar station D. Deze zendt dan op zijn beurt via C en B op dezelfde wijze een RR frame terug ten teken dat de data goed is aangekomen. Het station A ontvangt dus na 6 stappen een bevestiging van zijn frame. Hiervoor wordt een timer bijgehouden die rekening houdt met het aantal ingeschakelde digipeaters voordat er RR/P frames worden uitgezonden. Als echter op de route een frame verminkt raakt dan zal station A deze 6 stappen afwachten. Hierdoor gaat nogal wat van de snelheid verloren vooral als de verbindingen van slechte kwaliteit zijn. Vervolg deel 4 NETROM / THENET Men heeft hier echter het volgende op gevonden. We kunnen een verbinding maken volgens het netrom principe. De benaming NET-ROM komt af van een speciale Rom in de tnc welke de software in zich heeft om volgens dit netrom principe te kunnen werken. De stappen verlopen dan zoals tussen haakjes is aangegeven. Hierbij worden station A aan B, B aan C, en C aan D geconnect aan elkaar en geven de data via deze connect door. Het voordeel hiervan is dat de timing gebaseerd is op 1 station in plaats van 3 andere stations in dit geval. De data gaat van A naar B, deze stuurt direct een RR terug naar A en meteen als stap 3 de data door naar C, deze stuurt een RR terug naar B etc. Het blijven in totaal wel 6 stappen maar het grote voordeel is dat station A meteen nieuwe info kan gaan sturen als de eerste is aangekomen bij B. Het tweede grote voordeel is dat bij een storing tussen bv C en D de packet niet weer in het geheel van A naar D moet maar herhaald wordt vanaf C. Dit noemen we de zg node to node acknowledgement. De stations die volgens dit principe kunnen werken noemen we NODES omdat deze een knooppunt vormen in een netwerksysteem. Van deze nodes zijn er heel wat 24 uur per dag geactiveerd. We kunnen ze vergelijken met een telefooncentrale. Als u de telefoonhoorn opneemt wordt u verbonden met de centrale via deze centrale kunt u een andere centrale bereiken en vanaf daar de abbonee. Tussen de 2 centrales loopt een heleboel verkeer, meestal via een speciale kabel. Het Netrom / Thenet netwerk lijkt hierop. We maken eerst verbinding met de lokale node, vanaf daar maken we of verbinding met een andere amateur die zich in het bereik van die node bevindt, of we connecten een andere node. Vanaf die node kunnen we dan weer een eindgebruiker connecten. De verbinding naar een node toe noemen we een UPLINK. De verbinding tussen 2 nodes een CROSSLINK en naar de eindgebruiker toe een DOWNLINK. Via de Crosslink kunnen meerdere verbindingen lopen, (vergelijk de verbindingen tussen de telefooncentrales). Vaak vindt zo'n crosslink op een aparte frequentie plaats en spreken we van een BACKBONE frequentie. Ook worden deze crosslinks wel uitgevoerd met snelle modems op 9600 bps. Dit zorgt ervoor dat de snelheid van de verbinding aanzienlijk toeneemt t.o.v. het digipeatergebruik. Omdat echter via een crosslink meerdere verbindingen kunnen lopen moet echter via deze cl van ieder station apart de besturing worden doorgegeven. Men heeft hiervoor het NRS (netrom sliding window protocol) ontwikkeld wat van ieder station de besturingsgegevens doorgeeft. Dit levert weer een kleine overhead op van het protocol maar het resultaat is toch vaak beter als bij digipeaten. De netrom nodes houden elkaar onderling op de hoogte van welke buurnodes zij kunnen ontvangen en ook vaak welke nodes die buurnode kan ontvangen. Deze stations komen allemaal in een NODELIJST te staan. Alle nodes die direct worden ontvangen komen in een ROUTESLIJST te staan. Deze nodes en routes zijn op te vragen bij een node met het resp. nodes en routes commando. Verder krijgt iedere node een zg routekwaliteitsnummer wat wordt bijgehouden aan de hand van goed ontvangen nodelijst uitzendingen. Zodoende kan een route tijdens een verbinding nog wel eens veranderen als blijkt dat er een betere route onstaat. Bij de downlink willen we wel weer graag dat onze eigen call bekend is bij het tegenstation. Echter om problemen te voorkomen als we bv door condities het tegenstation direct horen, veranderd de netrom node onze ssid. De netrom verandert het h bit nl niet zoals bij een digipeater het geval is. Twee gelijke callsigns geven tegelijk antwoord op een ontvangen frame waardoor botsingen onstaan en de besturing van slag raakt. Van de ssid wordt het getal 15 afgetrokken (hexadecimaal F). Onze call wordt dan van pa0aaa-0 pa0aaa-15 op de downlink. TCP/IP Wat we verder onder de netwerksystemen kunnen rekenen is TCP/IP De laatste versies zijn ook compatibel met het netrom systeem. Het TCP/IP protocol (Transfer Control Protocol / Internet Protocol) is een protocol wat nogal eens gebruikt wordt bij zg. computer LAN (local Area Networks) en wereldwijde computerverbindingen via de ethernetkabel. Het protocol houdt een eigen structuur bij welke gedefinieert is met nummers. Ieder TCP/IP station heeft een zg. IP nummer wat afhankelijk is van het land en de regio waar die zich bevindt. Zo onstaat een net wat lijkt op de structuur van het telefoonnet. Omdat dit protocol z'n eigen besturing heeft is het niet noodzakelijk om dit met ax25 te besturen. Vandaar dat de meeste verbindingen dan ook unconnected lopen m.b.v UI frames. Het voordeel hiervan is dat bij zeer slecht lopende verbindingen toch de data overkomt. Bij een connected verbinding zou nl na een aantal retrys een disc frame automatisch worden uitgezonden en de verbinding verbreken. Echter in TCP/IP wordt gewerkt met een variabele timing die, indien een frame niet wordt ontvangen, steeds met langere tussenpozen zal proberen die over te krijgen. Dit ontlast de frequentie en zal bij qsb beter werken. Tenslotte zijn er de voordelen van meerdere mogelijkheden zoals file transfer om programma's over te sturen en een mailer om post te versturen en te ontvangen in een soort mini mailbox. Uiteraard kan men ook tekst oversturen en wel tegelijk met een file transfer. Ook meerdere file transfers tegelijk zijn mogelijk evenals meerdere connects tegelijk. Verder hebben de nieuwste versies netrom support en sommige versies een netdigi welke de adres structuur van een digipeater gebruikt maar toch werkt volgens het node to node ack systeem. Ook zijn er versies met een zg conference bridge. Hier kunnen meerdere stations elkaar tekst toesturen. Alle stations zijn in dit geval geconnect met de bridge en de tekst wordt voorafgegaan door de call van de afzender en gedistribueerd naar alle geconnecte stations. Om onderscheid te maken tussen de verschillende gebruikersmogelijkheden gebruikt een tcp/ip station meerdere ssid's. In Nederland worden de volgende SSID'S veel gebruikt. -1 testpoort en ssid's beschikbaar. -2 TCP/IP + netrom 2 meter -3 Netdigi 2 meter , -4 netdigi 70 cm -5 conference bridge 1 -6 conference bridge 2 ,-7 TCP/IP + netrom 70 cm. De netdigi's kunnen ook als GATEWAY worden gebruikt. Een gateway is een digipeater die op verschillende frequenties werkt. Zo is via de netdigi -4 vanaf 2 meter op 70cm te komen, deze netdigi -4 kan echter ook als digipeater op 70 cm gebruikt worden. Hetzelfde geldt ook voor de netdigi -3 die van 70cm naar 2 meter kan digipeaten of alleen op 2 meter gebruikt wordt. BULLETIN BOARDS (BBS) Bulletin boards treffen we ook heel wat aan op de packet radio frequenties. Velen zijn ook 24 uur per dag qrv en zijn in staat om post van gebruikers te plaatsen op een zg. prikbord en deze dan weer door degene die dat bericht wil zien te laten lezen. Er kunnen zowel algemene berichten (BULLETINS) of prive berichten in geplaatst worden. De meest gebruikte BBS'en gebruiken software van WA7MBL en W0RLI. De commandostructuur is gelukkig echter vrijwel hetzelfde bij beide software pakketen. Het fraaie van het systeem is dat berichten via FORWARDING over de gehele wereld verspreid kunnen worden. De bulletin boards zenden nl de bulletins en de priveberichten die naar een andere bestemming moeten naar elkaar toe en verspreiden dat zo door een groot gebied. Dat gebied kan de gebruiker die het bericht invoerd al van te voren aangeven. Ook kan hij aangeven naar welk bbs dit bericht gestuurd moet worden. Hiervan even een voorbeeld: Een bericht laten we achter met het S (send) commando. Bv. SP pa0aaa betekend zend privebericht aan pa0aaa. Dit bericht kunnen andere gebruikers niet opvragen omdat het een privebericht is. Als pa0aaa echter connect met het bbs krijgt hij een melding dat er een bericht voor hem is. Hij leest dat bericht met het RM (read mail) commando. Als hij het bericht gelezen heeft dan kan hij het wissen met het KM (kill mail) commando. Nog een voorbeeld SB DC64 @ PANET. zend bulletin aan DC64 (digicom 64 gebruikers) en forward dit bericht door heel nederland (panet). Dit bericht zal automatisch door heel nederland verspreid worden. Het is een bulletin dus door iedereen te lezen. DC64 is ingevoerd om speciale zoekmethoden te kunnen gebruiken. Voor panet kunnen we ook het bbs opgeven waar het bericht naartoe moet. Met het L (list) commando krijgen we een overzicht van alle berichten, die we sinds de laatste keer dat we connect hadden met het bbs, nog niet hebben gelezen. Alle berichten zijn genummerd waardoor ze op speciale manier terug te vinden zijn. Met het R (read) commando kunnen we berichten lezen. Vb. R 123 125 betekend lees bericht 123 en 125. Het list commando kent ook nog wat mogelijkheden die ik hier zal opsommen: LL 20 = list laatste 20 berichten. LN = list alle berichten die je nog niet gelezen hebt. L> DC64 = list alle berichten die aan DC64 gestuurd zijn. En zo zijn er nog wel meer maar dit zijn de belangrijkste. Verder bevat het bbs nog een filegebied voor ascii en binaire files. De ascii files zijn tekstfiles die door iedereen te lezen zijn. Een overzicht kan men vragen met het W (where) commando, waarna men het met D (download) kan opvragen door achter de D de naam van het file te zetten. Met U (upload) kan men een file achterlaten in de bbs. Voor IBM en compatibles is er verder nog een protocol YAPP genaamd wat transport van binaire files mogelijk maakt. Deze commando's werken soortgelijk aan de ascii file commando's maar hebben een Y ervoor. Ik weet dat ik nog niet echt alle aspekten van packet radio heb behandeld maar ik hoop hier toch aan te geven dat het echt wat meer is als alleen met een computer tekst naar elkaar toesturen. Packet radio is nog steeds in volle ontwikkeling en geniet een grote populariteit. Ik hoop dat andere zend- en luisteramateurs wat meer begrip krijgen voor die krijsende toontjes op de band. Verder hoop ik dat een nieuwkomer zich niet laat afschrikken vanwege alle kennis die nodig is om packetradio te bedrijven want die valt echt wel mee. Tenslotte is iedereen eenvoudig begonnen en je hoeft absoluut geen computerexpert te zijn om packetradio te kunnen bedrijven. Ik hoop spoedig meerdere packetgebruikers te kunnen begroeten op de band en wens iedereen veel plezier met deze hobby. Einde packet info