H.-P. Helfert, DL6MAA, Gustav-Mueller-Str. 8 , D-8948 Mindelheim U. Strate, DF4KV, Lommerwiese 18, D-5330 Koenigswinter 1 PACTOR - Einfuehrende Protokollbeschreibung (Level 1) ====================================================== (Stand: 5. November 1990) Zielsetzungen ------------- PACTOR (PT, lat.: "der Vermittler") wurde von Funkamateuren fuer Funkamateure im Rahmen des Experimentierfunkdienstes entwickelt; eine kommerzielle Nutzung ist nicht vorgesehen. PACTOR soll den derzeit bestehenden Mangel an einer zuverlaessigen und schnellen Fernschreibbetriebsart auf Kurzwelle, besonders fuer die Bereiche unterhalb 10 MHz, beseitigen. Auf folgende Punkte wurde beim PT-Design besonderer Wert gelegt: >>> Fehlerfreie Datenuebertragung (praktisch: Fehlerquote kleiner 10 ** -5 ) >>> Echte binaere Datenuebertragung (z. B. kompletter ASCII-Zeichensatz) >>> Gute Ausnutzung der aktuellen Kanalkapazitaet (automatische Anpassung der Schrittgeschwindigkeit, vollstaendig bitsynchrone Uebertragung, Memory-ARQ, keine speziellen Requestbloecke) >>> Sehr kleiner noetiger Stoerabstand fuer Aufrechterhaltung einer Verbindung >>> Einfache Betriebsabwicklung, optimierter Halbduplexbetrieb mit schnellem Richtungswechsel und beidseitig bestaetigtem QRT >>> Shiftlagenneutralitaet (Mark- und Spacedefinition entfaellt) >>> Realisierbarkeit mit einfacher Hardware (Level 1 auch fuer Portabel- und Notfunk verwendbar an uebli- chen Amateurfunkgeraeten) >>> Noetige Bandbreite maximal 600 Hz >>> Vollstaendige Transparenz fuer Dritte (z. B. behoerdliche Ueber- wachung) >>> Kompatibilitaet zu Erweiterungen durch Level-Definition und das Supervisorkonzept. Folgende Erweiterungen sollten bei Einfuehrung leistungsfaehigerer Hardware erprobt werden: * Effizientere Quellencodierung (z. B. Markow-Codierung) * Adaptive fehlerkorrigierende Kanalkodierung * Modifiziertes Memory-ARQ * Modemschaltungen mit Signalprozessoren zur bitsynchronen Demodulation und automatischen Frequenzgangkorrektur bzw. zur Erprobung neuer Modulationsverfahren * Hoehere Schrittgeschwindigkeiten fuer QRG's > 10 MHz (automatische Umschaltmoeglichkeit auf Modus 200/400 Bd) Protokoll-Grundzuege -------------------- Das PACTOR-Grundschema aehnelt der AMTOR-Struktur, die sehr gut an den auf Kurzwelle ueblichen Dialogbetrieb angepasst ist. Es handelt sich um Halbduplex-ARQ: Datenpakete (Bloecke), die die Nutzinformation tragen, werden durch kurze Quittungssignale (Controls) der empfangenden Station bestaetigt. Im Fehlerfall kann der Blockempfaenger durch entsprechende Controls Wiederholungen eines Datenpaketes anfordern. * Synchronbetrieb Um die verfuegbare Kanalkapazitaet gut auszunutzen, bedarf es einer bitsynchronen Uebertragung. Der Synchronismus muss dabei waehrend der gesamten Verbindungsdauer aufrechterhalten werden. * Paketlaenge Eine laengere Versuchsreihe hat gezeigt, dass es fuer den Betrieb in stark fluktuierenden Kanaelen nicht sinnvoll ist, die Datenpaketlaenge an die aktuellen Bedingungen automatisch anzupassen. Eine Aenderung des Zeitrasters fuehrt besonders in schlechten Kanaelen zu Ueberschneidungen von Datenbloecken und Controls, so dass diese Methode als unwirtschaftlich verworfen wurde. Die Frage nach der guenstigsten Paketlaenge wurde durch Ausmesssen verschiedener Kurzwellenkanaele mit einer FSK-Uebertragung beantwortet. Die gewonnenen Daten wurden durch eine Computersimulation auf ARQ-Systeme uebertragen. Als im Langzeitmittel optimale Kurzwellen-Paketlaenge ergab sich dabei eine Dauer von etwa einer Sekunde. Die Zyklusdauer (Paketlaenge + Empfangspause) sollte in jedem Fall deutlich kleiner als die haeufigste Fading-Periodendauer sein. Bei der Computersimulation gehen auch kurze Stoerimpulse ein; ohne Beruecksichtigung dieser "Bursts" koennte die Paketlaenge erheblich ver- groesert werden. Alternativ koennte das Problem kurzer Fehlerbuendel aehnlich wie in der digitalen Audiotechnik durch Anwendung fehlerkorrigierender Faltungscodes geloest werden. Deren Vorteile machen sich im allgemeinen aber erst bei bekannter, annaehernd konstanter Kanalqualitaet bemerkbar. Eine Verkuerzung der Paketlaengen kommt im uebrigen der Betriebstechnik (kurze Break-In-Zeiten) entgegen. * Paketsicherung Die Datenbloecke werden durch CRC gesichert. Die Anwendung fehlerkorrigie- render Codes ist zunaechst nicht vorgesehen, kann jedoch in spaeteren aufwaertskompatiblen Versionen in Verbindung mit leistungsfaehigerer Hard- ware realisiert werden. * Nutzung fehlerhafter Pakete Um die in fehlerhaft empfangenen Paketen enthaltene Information zu nutzen, bedient sich PACTOR eines Memory-ARQ-Verfahrens (s. u.), das eine deutliche Steigerung der Uebertragungsrate bei geringen Stoerabstaenden bewirkt. * Anpassung der Schrittgeschwindigkeit Die Informationsgeschwindigkeit im realen Kanal ist einerseits durch die verfuegbare Bandbreite (bei gegebenem Stoerabstand) und andererseits bei binaerem FSK auch durch auftretende Phasenverzerrungen infolge Mehrwegeausbreitung begrenzt. Auf Kurzwelle konnten mit 200 Baud besonders waehrend der Tagesstunden gute Ergebnisse erzielt werden. Am Abend treten verstaerkt Laufzeitver- zerrungen auf, die eine Reduzierung der Schrittgeschwindigkeit auf 100 Baud erforderlich machen. PACTOR verfuegt ueber eine automatische Steuerung zur Umschaltung auf die jeweils guenstigste Schrittgeschwindigkeit. Die Protokolldetails -------------------- Grundsaetzliche Begriffe: MASTER = Station, die den Verbindungsaufbau initiiert. SLAVE = die angerufene Station TX = Sender von Informationspaketen RX = Empfaenger von Informationspaketen BK = Break-In , vom RX ausgeloester Senderichtungswechsel Im folgenden wird von einer byteweisen Datenorganisation ausgegangen, da dies der Realisierung auf Mikrorechnern entgegenkommt. Das niederwertigste Bit wird zuerst ausgesendet. Die Shiftlage der FSK-Aussendung wird einmalig beim Verbindungsaufbau fixiert. Mit jedem neuen Paket oder Kontrollsignal wird die Shiftlage invertiert. * Timing PACTOR arbeitet als bitsynchrones System mit einem festen Zeitraster. Gesamt-Zyklusdauer : 1.25 sec Paketdauer : 0.96 sec Fenster fuer Kontrollsignalempfang : 0.29 sec Kontrollsignaldauer : 0.12 sec Es verbleibt eine Restzeit von 170 ms fuer Umschaltvorgaenge und die Signallaufzeit, so dass sich wie bei AMTOR eine maximale DX-Entfernung von ca. 20000 km ergibt (geringfuegige Korrekturen gegenueber cq-DL 11/90). Systemtakt-Betriebsmodi: 1) Intern (Standardmodus): Quarzzeitbasis mit Genauigkeit 15 ppm oder besser. Der SLAVE-Takt wird auf den MASTER-Takt synchronisiert (Auswertung der Flankenwechsel). 2) Extern (vorgesehen fuer Spezialanwendungen): Beide Stationen leiten ihren Systemtakt von einer Zentralquelle (z. B. 50-Hz-Verbund, TV- Zeilenfrequenz, DCF77) ab. * Kontrollsignal- und Paketaufbau Die Kontrollsignale (CS) werden vom RX als Empfangsbestaetigung ausgesen- det. Wiederholung des gleichen CS bedeutet 'REQUEST', d. h. die Anforderung einer Blockwiederholung. CS3 bildet den Kopf des BK-Paketes, CS4 fordert einen Geschwindigkeitswechsel an (s. u.). Die CS haben eine einheitliche Laenge von 12 Bit und werden stets mit einer Schrittgeschwindigkeit von 100 Baud ausgesendet. Die Bitmuster sind so gewaehlt, dass sich optimale Hammingdistanz (8 Bit) und guenstige Symmetrieeigenschaften ergeben. Bezeichnung Funktion Bitmuster(HEX) -------------------------------------------------- CS1 Bestaetigung 4D5 CS2 Bestaetigung AB2 CS3 Break-In 34B CS4 Speedchange D2C Alle Pakete, ausgenommen Spezialfaelle, bestehen aus den drei Teilen Kopf (Header), Datenbereich und Verwaltungsteil (Status + CRC). Aufbau der Datenpakete 100 Baud : /Header/ Datenbereich 64 Bit /Statusbyte/CRC1/CRC2/ 200 Baud : /Header/ Datenbereich 160 Bit /Statusbyte/CRC1/CRC2/ Erlaeuterungen: 1) Header : Bitmuster 55(HEX) Das Kopfbyte liefert Zusatzinformation, die zur Synchronisation, zur REQUEST-Erkennung bei Memory-ARQ sowie beim Monitor-Modus genutzt wird. Bei jedem Paket, das neue Information enthaelt, wird das Bitmuster invertiert. 2) Datenbereich: Der Datenbereich kann beliebige Binaerinformation enthalten; die Art der Codierung wird im Statusbyte angegeben. Gegenwaertig kann zwischen 8-Bit- ASCII und 7-Bit-ASCII (Huffman-komprimiert) gewaehlt werden. Das ASCII- Zeichen RS (1E HEX) dient in beiden Faellen als IDLE-Symbol. Der Huffman-Code eignet sich besonders zur Uebertragung von deutschem und englischen Klartext. Die resultierende mittlere Symbollaenge betraegt ca. 4,5 Bit. Jedes Paket stellt eine Informationseinheit dar: Passt ein Symbol nicht mehr komplett in ein Paket, wird es im naechsten Datenpaket gesendet. Eine Code-Tabelle findet sich im Anhang. 3) Statusbyte-Belegung: Bit 0: Paketzaehler (LSB) Bit 1: Paketzaehler (MSB) Datenmodus Bit 3 Bit 2 Bit 2: Datenmodus (LSB) --> ----------------------------- Bit 3: Datenmodus (MSB) --> ASCII-8-Bit 0 0 Bit 4: noch nicht belegt Huffman-Code 0 1 Bit 5: noch nicht belegt nicht bel. 1 0 Bit 6: BK-Anforderung nicht bel. 1 1 Bit 7: QRT-Bit Die Bits 0 und 1 dienen als Paketzaehler; aufeinanderfolgende Pakete mit gleichem Zaehlerwert werden vom RX als REQUEST-Pakete erkannt. Die modulo- 4-Zaehlung ermoeglicht die Behandlung des (in der Praxis sehr unwahr- scheinlichen) Falles nicht erkannter Kontrollsignalfehler. 4) CRC-Bytes: Der CRC wird nach CCITT-Norm ueber das gesamte Paket, beginnend mit dem Datenbereich (d. h. ohne Header bzw. CS3 bei BK-Paketen) berechnet. * Aufbau einer PACTOR-Verbindung Vom MASTER werden Synchronisationspakete mit folgendem Aufbau ausgesendet: /Header/S L A V C A L L/SLAVCA/ (Header= 55 HEX) /<------100 Baud------>/200Bd / Diese Pakete enthalten das SLAVE-Rufzeichen (max. 8 Byte, ASCII-Codiert) als 100 Baud- und 200-Baud-Bitmuster. Bei kuerzeren Rufzeichen werden Leerbytes mit 0F(HEX) aufgefuellt. Die SLAVE-Station sucht den einlaufen- den Bitstrom nach Synchronisationspaketen mit ihrem Rufzeichen ab (Beide moeglichen Shiftlagen werden geprueft) und antwortet nach erfolgreicher Synchronisation mit der Aussendung von CS. Die eigentliche Synchronisation wird mit dem Head-Byte und einer waehlbaren Anzahl Bytes des ersten Rufzeichenteils vorgenommen. Das 200 Bd-Muster dient lediglich zur Ueber- pruefung der Kanalqualitaet. Wird es fehlerfrei empfangen, wird mit CS1 geantwortet, ansonsten mit CS4, was zur sofortigen Geschwindigkeitsredu- zierung auf 100 Baud fuehrt. Analog dazu sucht der MASTER im Empfangsfenster zwischen zwei Paketen nach gueltigen CS in beiden Shiftlagen. Sobald das erste gueltige CS empfangen und synchronisiert ist, wird das erste normale Datenpaket mit Head=AA (HEX) und Paketzaehler=1 ausgesendet. * Levelfestlegung beim Verbindungsaufbau Beim Verbindungsaufbau ist der maximal moegliche Systemlevel der Gegenstelle unbekannt, daher wird jede Verbindung zunaechst auf dem kleinsten Level (1) gestartet. Die ersten uebertragenen Zeichen enthalten Informationen ueber maximal verfuegbare Software-Levelnummer, gefolgt vom MASTER-Rufzeichen, abge- schlossen mit CR (Beispiel : 1DF4KV ). Stellt die SLAVE-Station eine Ueberforderung fest (kleinerer eigener Systemlevel), teilt sie dies dem MASTER mittels BK und Supervisorinformation (s. u.) sofort mit, ansonsten wird die Verbindung auf dem angegebenen MASTER-Level fortgesetzt. Die User-BK-Moeglichkeit ist erst mit Abschluss der MASTER-Systeminfor- mation () freigegeben. * Senderichtungswechsel Nach einem korrekt empfangenen Paket kann die RX-Station mittels BK- Kontrollsignalen (CS3) eine Umkehrung der Senderichtung anfordern. Das CS3 bildet bereits den Kopf des ersten, vom neuen TX ausgesendeten Datenpake- tes. Bei 200 Baud belegt das CS3 die ersten drei bei 100 Baud, die ersten zwei Bytes des Paketes, wobei in diesem Fall 4 Bit unbenutzt bleiben. Der CRC wird wie beim normalen Datenpaket erst vom Beginn des Datenbereichs an berechnet, der Paketzaehler wird auf 0 gesetzt. Das naechste Datenpaket nach einem BK-Paket erhaelt als Header 55(HEX). Empfaengt der TX ein CS3, schaltet er sofort in den RX-Modus und liest das Restpaket vollstaendig ein. Bei fehlerfei empfangenem Paket antwortet er mit CS1, bzw. CS3, falls ein sofortiges "Rebreak" gewuenscht wird. Eine Wiederholung des BK-Paketes wird mittels CS2 angefordert. Die Antwort-CS auf ein BK-Paket beginnen im Zeitraster eine CS-Laenge (0.12 sec) vor Ende des alten eigenen TX-Blocks. Durch Setzen von Bit 6 im Statusbyte kann der TX auch selbst ein BK anfordern, da dieser Status den RX zur Bestaetigung mit CS3 veranlasst. * Geschwindigkeitsverminderung 200 --> 100 Baud Der RX kann immer nach einem fehlerhaften Paket ein CS4 senden, was auf der TX-Seite immer als "REJECT" interpretiert wird: Das gerade gesendete, nicht bestaetigte Paket wird verworfen und die in ihm enthaltene Information erneut im 100-Baud-Modus ausgesendet. Der Paketzaehlerwert des ersten 100-Bd-Paketes wird vom verworfenen 200-Baud-Paket uebernommen. Empfaengt der RX einen 100-Bd-Block mit gleichem Paketzaehler wie im vorangegangenen 200-Bd-Paket, so bedeutet dies doppelt aufgenommene Information: Es muessen soviele Zeichen (ausgenommen IDLE) von der Ausgabe ferngehalten werden, wie im letzten 200-Bd-Paket ankamen. Nach einem "speeddwn"-CS4 stellen RX und TX den Header auf 55(HEX), um korrekte Memory-ARQ-Funktion (s. u.) sicherzustellen. Sonderfaelle: 'REJECT' eines QRT-Paketes: --> Aussenden eines 100-Bd-QRT-Paketes 'REJECT' eines BK-Paketes : --> Aussenden eines normalen 100-Bd-Paketes mit Head= 55(HEX) statt des CS3-Kopfes. CS4 dient als "REQUEST"-CS fuer den ersten 100-Bd-Block, Bestaetigung erfolgt mittels CS1 oder CS3, danach kann bereits wieder ein CS4 als "speedup"-Signal gesendet werden (s. u.). * Geschwindigkeitserhoehung 100 --> 200 Baud Der RX kann nach jedem richtig empfangenen 100-Bd-Paket (ausgenommen "REQUEST"-Pakete) mit CS4 bestaetigen, was den TX zur Umschaltung auf 200 Baud zwingt. Der RX schaltet sofort nach CS4-Aussendung auf 200-Baud- Empfang. (Sollte der TX das CS4 nicht erhalten, so ist dies nicht mit zusaetzlichem Informationsverlust verbunden, obwohl der RX bereits die "falsche" Geschwindigkeit eingestellt hat. Das neue Paket waere ein "Request"-Paket, also irrelevant.) CS4 in Folge (ohne zwischenzeitliches richtiges CS) werden als "Request" interpretiert, also ignoriert. Nach erfolgreicher Geschwindigkeitserhoehung muss mindestens noch ein zweites 200-Bd-Paket vor dem naechsten CS4 ("speeddown) empfangen werden. Ablehnungsmoeglichkeit: Erhaelt der RX nach dem CS4 nicht spaetestens nach einer vorgewaehlten Anzahl Zyklen ein fehlerfreies 200-Bd-Paket, so antwortet er mit einem OK- CS (verschieden vom letzten CS vor dem CS4) und schaltet danach zurueck auf 100 Baud. Der TX muss seinerseits das auf CS4 folgende CS auf OK testen, in diesem Fall unverzueglich auf 100 Bd zurueckschalten und die 200 Bd-Information wiederholen (bzw. im QRT-Fall einen 100-Baud-QRT-Block aufbauen). * Supervisorkonzept Um Kompatibilitaet zu kommenden Software-Versionen zu gewaehrleisten, muss bereits im Level-1-Protokoll die Uebertragung von Systeminformationen (SI) moeglich sein. Zu diesem Zweck wird ein Supervisor-Zeichen (SB) definiert, das die normale Textausgabe auf die Systemebene umlenkt. Das auf das SB folgende Zeichen enthaelt den Supervisor-Funktionscode (SIC), gefolgt von Parametern. Den SI-Abschluss bildet ein . Vorlaeufige SI-Definitionen: SB: ASCII = 1C (HEX) SIC: A: Levelnummer folgt ('1' = Level 1) B: Mycall folgt (kann z. B. automatisch in IDLE-Pakete eingefuegt werden, um mitlesenden Dritten die Identifikation zu ermoeglichen) a .. : Controlzeichen ausgeben 01 bis 1F (HEX) ; ermoeglicht volle Datentransparenz Die gesamte SI laeuft wie gewoehnlicher Text ueber das PT-System, um Komplikationen beim Geschwindigkeitswechsel zu vermeiden. Sofort benoetigte SI muss in den laufenden Text eingeschoben werden, fruehestens nach dem letzten bereits (mindestens einmal) bearbeiteten Zeichen, um im Wiederholungsfalle Fehler zu vermeiden. * Beenden einer PACTOR-Verbindung Der Abschluss einer ARQ-Verbindung bring allgemein das Problem mit sich, dass Information ohne echte Bestaetigung gesendet werden muss, da immer wieder eine Bestaetigung der Bestaetigung noetig waere fuer einen definier- ten Verbindungsabbruch. PACTOR benutzt spezielle QRT-Pakete, um die Gefahr eines unkontrollierten QRT zu minimieren: 100 Baud: /Header/ G I S L L A C/Header/Satusbyte/CRC1/CRC2/ 200 Baud: /Header/X/ G I S L L A C/Header/XXX/Statusbyte/CRC1/CRC2/ /<------100 Baud------>/ (maximal 7 signifikante Bytes zulaessig) (X=beliebig) Das QRT-Paket wird je nach aktueller Geschwindigkeit nach obigem Schema aufgebaut, wobei das Rufzeichen der Gegenstation ab dem 17. 200-Bd-Daten- byte von rechts nach links stehen muss. Das Rufzeichen wird immer als 100- Bd-Bitmuster gesendet; das QRT-Bit im Statusbyte muss gesetzt sein. Wird ein QRT-Paket empfangen, sendet der RX noch ein Bestaetigungskontroll- zeichen und geht dann in den STBY-Zustand. Das QRT-Paket darf nicht mehr der Dekodierung (Ausdruck) zugefuehrt werden. Da es bei gestoerten Kanaelen sehr wahrscheinlich ist, dass das erste Be- staetigungs-CS nicht korrekt vom TX empfangen wird, muss der in den STBY- Zustand gegangene RX auch in der normalen Suchphase noch mit dem korrekten CS auf QRT-Pakete antworten. Der RX sucht dafuer den eingehenden Bitstrom nach dem bytereversen Rufzei- chen im QRT-Paket ab und synchronisiert gegebenenfalls darauf. Jedes empfangene QRT-Paket fuehrt zur Aussendung eines Betstaetigungs-CS, wobei die Shiftlage des CS sich nach der Shiftlage des QRT-Paketes richtet. Der RX muss sich dazu natuerlich die alte Relation (vor STBY) von CS-Shiftlage und Blockshiftlage merken; ausserdem muss der CS-Zeitpunkt gespeichert wer- den. * Memory-ARQ Normale ARQ-Systeme verzichten auf die in fehlrhaften Paketen enthaltene Information. Eine solche Vorgehensweise fuehrt bei geringer werdendem Stoerabstand sehr rasch zum Totalausfall einer Verbindung, da es extrem un- wahrscheinlich wird, ein Paket fehlerfrei zu empfangen. Memory-ARQ summiert die Empfangsspannung (Nutz- plus Rauschspannung) glei- cher (nocht nicht fehlerfrei aufgenommener) Pakete bitweise auf, wodurch sich der effektive Signal-Rauschabstand im Idealfall um den Faktor n (=An- zahl aufsummierter Pakete) erhoeht. Beispiel fuer Fall n=2 und konstanter Signal- und Rauschleistung: (N = Rauschspannung, S = Signalspannung, <..> = Mittelwert) * Summenspannung: 2*S + N1 + N2; * Leistung des Summensignales: <(2*S + N1 + N2)**2> = 4*S**2 + + + ; = 0; = = Rauschleistung; --> S/N verdoppelt bei n=2, analog fuer beliebige n. (Dies entspricht letztendlich nur dem Satz, dass die Bitenergie in den effektiven Signal- Rauschabstand eingeht --> spezielle Form des Energieerhaltungssatzes. Bit- laenge und Bitleistung einzeln betrachtet sind aussagelos. Memory-ARQ nutzt nutzt also die gesamte Signalenergie aus. Memory-ARQ senkt den noetigen Mindeststoerabstand fuer eine Verbindung um 1 - 15 dB ab. In realen, also fluktuierenden Kanaelen muss vermieden wer- den werden, dass Pakete mit relativ geringem Stoerabstand den Stoerab- stand des Summenpaketes wesentlich verschlechtern. Hierzu misst man den Stoerabstand ueber die gesamte Paketlaenge (relativ kleine Unschaerfe) und gewichtet die Summanden mit diesem gemessenen Paketstoerabstand. Um Quantisierungsrauschen minimal zu halten, wird ein 8-Bit A/D-Wandler zum Einlesen der Empfangsspannung empfohlen. In das PT-Protokoll sind zum Memory-ARQ folgende Punkte aufgenommen worden: Summenpakete, deren CRC passt, werden wie normale fehlerfreie Pakete behan- delt. (Da der 16-Bit CRC eine hohe Sicherheit gewaehrleistet, bringt Memo- ry-ARQ in der Praxis keinerlei Nachteile mit sich.) Alte "Request"-Pakete, die durch Stoerung eines OK-CS vom TX ausgesendet werden, duerfen nicht in die Summation gelangen. Hierzu fuehrt man einen "Similarity"-Test durch, der bei PACTOR aus der Ueberpruefung des Headbytes besteht. Bei neuen Paketen (mit neuer Informaton) wird der Header inver- tiert, so dass der RX auch ohne CRC (Stoerungsfall) erkennen kann, ob es sich um ein "Request"-Paket handelt. Jedes richtige Paket (CRC in Ordnung) fuehrt zur Loeschung der Memory-ARQ-Summen. Bei CS3-Paketen muss der "Similarity"-Test natuerlich mit dem CS3-Header durchgefuehrt werden. Das PT-Memory-ARQ ist dank der permanent wechselnden Shiftlage auch faehig, konstante Stoersignale (Traeger) oder andere Unsymmetrien im Kanal auszu- umitteln. Anhang ------ PT-Huffman-Code =============== Der Huffman-Code ist relativ unempfindlich gegenueber Abweichungen der realen von der theoretischen Buchstabenhaeufigkeit, so dass fast gleich gute Ergebnisse bei deutschem und englischem Klartext erreicht werden. Der erreichbare Kompressionsfaktor gegenueber ASCII betraegt ca. 1.7 (bei einer Entropie von 4.5 Bit/Zeichen). Wesentliche Verbesserungen koennten bei Beruecksichtigung der statistischen Abhaengigkeiten der einzelnen Zeichen erzielt werden (Markow-Quellencodierung). Code geordnet nach Haeufigkeit, LSB (uerst gesendet) links! space : 32 10 e : 101 011 n : 110 0101 i : 105 1101 r : 114 1110 t : 116 00000 s : 115 00100 d : 100 00111 a : 97 01000 u : 117 11111 l : 108 000010 h : 104 000100 g : 103 000111 m : 109 001011 : 13 001100 : 10 001101 o : 111 010010 c : 99 010011 b : 98 0000110 f : 102 0000111 w : 119 0001100 D : 68 0001101 k : 107 0010101 z : 122 1100010 . : 46 1100100 , : 44 1100101 S : 83 1111011 A : 65 00101001 E : 69 11000000 p : 112 11000010 v : 118 11000011 0 : 48 11000111 F : 70 11001100 B : 66 11001111 C : 67 11110001 I : 73 11110010 T : 84 11110100 O : 79 000101000 P : 80 000101100 1 : 49 001010000 R : 82 110000010 ( : 40 110011011 ) : 41 110011100 L : 76 110011101 N : 78 111100000 Z : 90 111100110 M : 77 111101010 9 : 57 0001010010 W : 87 0001010100 5 : 53 0001010101 y : 121 0001010110 2 : 50 0001011010 3 : 51 0001011011 4 : 52 0001011100 6 : 54 0001011101 7 : 55 0001011110 8 : 56 0001011111 H : 72 0010100010 J : 74 1100000110 U : 85 1100000111 V : 86 1100011000 : 28 1100011001 x : 120 1100011010 K : 75 1100110100 ? : 63 1100110101 = : 61 1111000010 q : 113 1111010110 Q : 81 1111010111 j : 106 00010100110 G : 71 00010100111 - : 45 00010101111 : : 58 00101000111 ! : 33 11110011101 / : 47 11110011110 * : 42 001010001100 " : 34 110001101100 % : 37 110001101101 ' : 39 110001101110 _ : 95 111100001100 & : 38 111100111001 + : 43 111100111110 > : 62 111100111111 : 64 0001010111000 $ : 36 0001010111001 < : 60 0001010111010 X : 88 0001010111011 # : 35 0010100011011 Y : 89 00101000110101 ; : 59 11110000110100 \ : 92 11110000110101 : 91 001010001101000 : 93 001010001101001 : 127 110001101111000 : 126 110001101111001 : 125 110001101111010 : 124 110001101111011 : 123 110001101111100 : 96 110001101111101 : 94 110001101111110 : 31 110001101111111 : 29 111100001101100 : 27 111100001101101 : 25 111100001101110 : 24 111100001101111 : 23 111100001110000 : 22 111100001110001 : 21 111100001110010 : 20 111100001110011 : 19 111100001110100 : 18 111100001110101 : 17 111100001110110 : 16 111100001110111 : 30 111100001111000 : 15 111100001111001 : 14 111100001111010 : 12 111100001111011 : 11 111100001111100 : 9 111100001111101 : 8 111100001111110 : 7 111100001111111 : 6 111100111000000 : 5 111100111000001 : 4 111100111000010 : 3 111100111000011 : 2 111100111000100 : 1 111100111000101 : 0 111100111000110 : 26 111100111000111 /*----------------------------------------------------------------------- * Datendurchsatzberechnung bei PACTOR * ohne/mit Memory-ARQ * Annahme: lineare Superposition * waa 10/90 *---------------------------------------------------------------------*/ /*----------------------------------------------------------------------- * Dieses c-Programm wurde kompiliert und ist * bei der Installation des hf-Pakets * in /usr/local/bin/paccalc installiert * und mit 'paccalc' aufrufbar. * dl4mge 5/03 * *---------------------------------------------------------------------*/ #include #include double sn,pp,pe,pss,psum,snx,db_min=-20.,db_step,db_max=15.; double bw=600.,baudr=200.,bwd2br,ln10d10,db,pneu,pa,x; int n,bits=192; main() { register int i,k,maxsum=400; bwd2br=bw/baudr/2.; /* Bandbreite/(2*Baudrate) */ ln10d10=log(10.)/10.; printf("\nEingabe Anzahl Datenpunkte :"); scanf ("%d",&n); db=db_min; db_step=(db_max-db_min)/(n-1); /* Schrittweite */ printf("\n Stoerabstand (dB) Durchsatz normal (%%) \ Durchsatz Memo-ARQ (%%) "); printf("\n---------------------------------------------------------\ ------------------"); for (i=0;i SN */ pe=0.5*exp(-sn*bwd2br); /* FSK-Bitfehlerwahrscheinlichkeit */ if (pe<0.1) pp=exp(log(1.-pe)*bits); /* Paket-OK-Wahrscheinlichkeit */ else pp=0.0; pss=pp; pp*=100.; printf("\t %8.3lf ",pp); pa=pss; psum=pss; for (k=2;k<=maxsum;k++){ /* Iteration fuer M-ARQ */ snx=sn*k; /* Ann. : lineare Stoerabstands- */ if (snx>50.) /* Verbesserung bei Memo-ARQ */ pe=0.0; else pe=0.5*exp(-snx*bwd2br); if (pe<0.1) pp=exp(log(1.-pe)*bits); else pp=0.0; pneu=(1.-pa)*pss; pa+=pneu; x=(1.-pa)*pp; pa+=x; psum+=x/k; } psum*=100.; printf("\t\t%8.3lf",psum); db+=db_step; } } EOF.