| |
DL6MAA > DSP 14.09.98 00:40l 239 Lines 13733 Bytes #-9674 (0) @ EU
BID : 139849DB0GV
Read: DF7ML DH9MAG DJ9KV LX2GT DG9ALL DJ5YS DJ5ZH DL2NBU GUEST DK5RAS
Subj: PSK31 und PTC-II etc.
Path: DB0AAB<DB0KFB<DB0CZ<DB0GE<DB0LJ<DB0GV
Sent: 980913/2127z @:DB0GV.#HES.DEU.EU [Frank4t/Mtl OP:DF5FF] $:139849DB0GV
de DL6MAA @ DB0GV.#HES.DEU.EU (Peter)
to DSP @ EU
Liebe PACTOR-Freunde und DSP-Spezialisten,
da in einigen Beiträgen zu PSK31 nun auch der Vergleich mit PACTOR-II auf-
taucht, will ich zu der Materie Stellung nehmen:
Ich verfolge die Veröffentlichungen zu PSK31 seit November 1997 und habe
mir durchaus schon ernsthaft überlegt, dieses Verfahren auch als kosten-
loses Update für den PTC-II zu implementieren. Allerdings möchte ich noch
abwarten, ob sich PSK31 wirklich auf breiter Basis durchsetzt. Eine Vor-
reiterrolle sollte der PTC-II hier nicht einnehmen. Ich habe bereits vor
einigen Jahren hochruboste Broadcast-Verfahren für kommerzielle Funkdienste
entwickelt und würde ein neues Broadcast-Verfahren für die Funkamateure an-
ders designen als PSK31! Hauptsächlich die sehr kleine Bandbreite (oft als
DER Vorteil des PSK31-Verfahrens hervorgehoben) halte ich für ungünstig.
Es besteht keine physikalische Notwendigkeit, die Bandbreite durch die vor-
gegebene Datenrate (ausreichend für flüssige QSOs) festzulegen. Die Kurz-
wellenbänder werden immer leerer - ein modernes Broadcast-Verfahren sollte
an die physikalischen Grenzen der ROBUSTHEIT herankommen. Ich würde ähnlich
wie für PACTOR-II eine Bandbreite von 500 Hz vorschlagen - hier besteht die
entsprechende Infrastruktur (500 Hz-ZF-Filter). Ferner hat diese Bandbreite
auch betriebstechnische Vorteile: Die nötige Abstimmgenauigkeit kann erheb-
lich verringert werden (bei PACTOR-II z. B. +- 80 Hz), und ein 500 Hz-Kanal-
raster erleichtert das Auffinden der Gegenstationen.
Rein theoretisch betrachtet kann durch Erhöhung der Bandbreite bei gegebener
Datenrate die Robustheit verbessert werden (Shannon). Ein breitbandigeres
Verfahren ist natürlich auch robuster gegen Schmalbandstörer. Man nennt die-
sen Effekt bei Spread Spektrum "System-Gewinn". (Ein schwacher Pfeifton stört
nicht, egal in welchen Spektralbereich des "Breitband"-Verfahrens er auch
fällt. Ein schwacher Pfeiton im engen PSK31-Empfangsfenster ist jedoch ein
ernsthaftes Problem.)
Natürlich ist die Wahrscheinlichkeit dafür, daß ein Störer überhaupt in das
Empfangsspektrum fällt bei einem Schmalbandverfahren kleiner.
Ich möchte hier auf keinen Fall den Eindruck erwecken, daß PSK31 ein
"schlechtes" Verfahren sei.
Nach meiner Überzeugung ist PSK31 gerade deshalb eine interessante Sache,
weil es auch auf relativ langsamen PCs mit Soundkarte, also OHNE DSP, im-
plementierbar sein sollte. Peter Martinez hat sich als AMTOR-Vater einen
Namen gemacht - ich kenne ihn seit vielen Jahren als hervorragenden Prag-
matiker, der ein "Händchen für sinnvolle Kompromisse" hat. Seine Veröffent-
lichungen zu AMTOR waren hier 1982 überhaupt erst der Anreiz, mich mit ARQ-
Verfahren zu befassen.
PSK31 hat gerade deshalb, weil es leicht implementierbar ist, das Potential,
"Dampf-RTTY" abzulösen. Wenn ich über die "digitalen" Bereiche der Kurz-
wellenbänder drehe, bin ich immer wieder erstaunt, wie viel Baudot-RTTY
auch heute im DSP-Zeitalter noch praktiziert wird. Ich vermute mal, daß
dies vor allem an der sehr unkomplizierten Handhabung und der leichten
Verfügbarkeit liegt.
Genau hier könnte PSK31 ansetzen: Durch die sehr kleine Schrittgeschwin-
digkeit und das fehlende Interleaving bzw. Spreading lassen sich sehr
effiziente Dezimierungstechniken einsetzen, so daß der Rechenzeitbedarf bei
geschickter Programmierung außerordentlich klein wird, z. B. im Vergleich
zu PACTOR-II. Eine Implementierung auf einem 486er mit 66 MHz halte ich
für durchaus machbar. Mal sehen, was die "DSP"-Freaks uns da in nächster
Zeit bescheren, hi.
73 etc.
de Peter
ANHANG:
-------
Abschließend möchte ich noch ein paar Dinge kommentieren, die mir in den
Beiträgen anderer OM, speziell Alexander, DL8AAU, hier in der Rubrik auf-
gefallen sind.
>>der Pactor-2 Controller hat PSK seit 1994 als fest implementierter Bestandteil.
>>Nur bereits wesentlich besser + schneller und auch weiterentwickelt
>Das würde ich so nicht sagen, da das Protokoll niemals veröffentlicht wurde,
>weiß ich nicht, ob es wirklich besser, schneller und weiterentwickelt ist.
>Soweit ich allerdings weiß, wird eine codierte DPSK verwendet. PSK-31 verwendet
>im QPSK-Modus *auch* eine codierte DPSK. Also wo liegt der Unterschied?
>Doch wohl lediglich in der Geschwindigkeit, die - wenn man die Bandbreite von
>PACTOR-II auf die Bandbreite von PSK-31 runterskaliert - auch nicht so doll
>ist.
Das PACTOR-II-Protokoll wurde bereits 1994 relativ ausführlich im amerika-
nischen Digital Journal durch Tom, DL2FAK, und mich beschrieben.
Es handelt sich auch bei PACTOR-II um ein codiertes DPSK, allerdings mit
"full frame interleaving" und zwei Trägern anstatt nur einem bei PSK31.
Anders als bei PSK31 ist die Filterung "Root Raised Cosine" und zwar wirk-
lich als "matched filter design". Als Code wird ein Faltungscode mit k=9
eingesetzt. Durch das enge zeitliche ARQ-Raster und das "full frame inter-
leaving" kann das gesamte Paket erst am Ende decodiert werden. So müssen
also bis zu 1000 Signalschritte in 20 Millisekunden durch den Viterbi-
decoder gepresst werden. Im Vergleich hierzu muß bei PSK31 nur 1 Schritt
in 32 Millisekunden durch den Decoder laufen.
>Memory-ARQ war für PACTOR-I sicher eine tolle Erfindung, bei der Hardware, die
>der PTC-II bietet, ist es aber ziemlich übel. Wenn man bei Memory-ARQ zwei
>Frames miteinander "verbindet", so erhöht man im Prinzip die Sendeleistung um
>den Faktor 2. Andererseits hat man jetzt aber alles doppelt gesendet. Daraus
>ergibt sich ein "Gewinn" von 3dB bei einer Coderate von 1/2. Das ist
>*sauschlecht*. Der bei PSK-31 verwendete Faltungscode hat ca. 5dB bei Rate 1/2,
>der bei Pactor-II verwendete noch ein halbes dB mehr (bei 4fachem Aufwand!).
>Wesentlich günstiger, als Memory-ARQ wäre Hybrid-ARQ II, bei dem nicht das
>nicht zu dekodierende Frame einfach wiederholt würde (repetition coding),
>sondern mehr Redundanz gesendet wird (kann man das z.B. prima mit dem
>Punktieren kombinieren - das, was man vorher weggelassen hat, sendet man
Der Codierungsgewinn bei reinem Memory-ARQ ist nicht 3 dB sondern 0 dB -
es handelt sich in der Tat um einen "repetition code".
Ich habe mich bei der PACTOR-II-Entwicklung auch ausführlich mit Hybrid-II-
Verfahren befaßt. Abgesehen davon, daß sie "engere" Kanalmodelle benötigen,
um ihre Vorteile ausspielen zu können, gibt es einen sehr einfachen Grund,
daß ich darauf verzichtet habe: Ein umfassender Mitlese-Modus ist Grund-
voraussetzung für ein AFU-Verfahren. Bei der Anwendung nichtsystematischer,
nichtinvertierbarer Codes in einem Hybrid-II-Verfahren wäre diese Voraus-
setzung nicht mehr gegeben. Die Implementierung des Mitlesemodus war auch
beim jetzigen PACTOR-II-Verfahren bereits sehr aufwendig!
Der mögliche Gewinn eines Hybrid-II-Verfahrens gegenüber dem im PTC-II ein-
gesetzten Memory-ARQ ist KLEIN, anders als auf dem Papier. Der Grund hier-
für: Der PTC-II gewichtet die Analogdaten auch innerhalb des Paketes, da er
durch die Metrik des Viterbidecoders abschätzen kann, wie zuverlässig das
Signal im "Augenglick" gerade ist. Ich nenne diese Methode "Modified Memory
ARQ".
Alexanders Gewinnangaben sind übrigens unvollständig, denn er muß sie auf
eine Bitfehlerrate beziehen. Bei PACTOR-II kommt es eben gerade darauf an,
bei Fehlerraten, die größer als 1/100 sind, noch ALLE FEHLER zu korrigieren.
Normalerweise beziehen sich Gewinnangaben auf BER = 10E-5 und haben mit der
harten Kurzwellen-Realität nichts zu tun. In meinen Simulationen ergibt sich
ein praktischer Gewinn zwischen dem Industrie-Standardcode k=7 und dem Fal-
tungscode bei PACTOR-II von knapp 1 dB. Das mag wenig erscheinen, aber man
merkt den Unterschied noch ganz deutlich, denn es handelt sich um Gewinn,
der auch direkt auf Multipath-Effekte wirkt.
>Pactor-II ist sicher ein richtiger Ansatz. Leider wurde er nicht konsequent bis
>zum Ende verfolgt. Das Konzept - soweit man es trotz fehlender Dokumentation
>durchschauen kann - krankt an ziemlich vielen Ecken. So wird differentielle
>PSK mit relativ hoher Baudrate verwendet. Durch die schnellen Schwund-
>erscheinungen auf KW treten auch ohne Störungen Bitfehler auf, die zwar durch
>die Fehlerkorrektur wieder korrigiert werden können, aber dies führt zu einer
>deutlichen Verschlechterung. Soweit ich weiß, wird bei Pactor-II immer noch mit
>Pactor-I der Verbindungsaufbau gemacht, dies kann sich allerdings inzwischen
>geändert haben. Insofern relativieren sich die -18db unter dem Rauschen (tolle
>Angabe übrigens, das hängt ja wohl von der Bandbreite ab!!!) wieder, bei dem
>geringen S/N bekommt man keine Pactor-I Verbindung hin.
>Also: PA an, Verbindung aufbauen, PA aus, Sendeleistung zurückdrehen.
PACTOR-II wurde sehr konsequent bis zum Ende durchdacht. Wenn jemand das
Gegenteil behauptet, kennt er sich eben nicht gut genug mit der Materie aus,
auch wenn er evtl. mit OFDM Erfahrung hat, hi.
Natürlich hat differentielle PSK auch Schwächen, z. B. eine irreduzible
Bitfehlerrate im Rayleigh-Fading. Im PTC-II wird die DPSK jedoch z. B. teil-
weise cohärent ausgewertet, es handelt sich dabei um einen "Differentiellen
Phasendetektor, DPD", der durch "decision feedback" die Trägerphase re-
konstruiert. Dies vermindert die Bitfehlerrate durch Fading erheblich.
Ausführliche Simulationen - auch an sehr teuren Ionosphärensimulatoren -
haben gezeigt, daß die 100 Bd Schrittgeschwindigkeit in der Praxis ein sehr,
sehr guter Kompromißwert ist. Seit "CLOVER" kursiert offenbar die Meinung,
daß niedrige Schrittgeschwindigkeiten ein Allheilmittel gegen "Multipath-
Effekte" sind. Dies ist NICHT der Fall. Zu kleine Schrittgeschwindigkeiten
haben z. B. gerade bei differentiellen Verfahren im Fading NACHTEILE.
Der PTC-II muß aufgrund des Kompatibilitätsanspruches auch bei PACTOR-II mit
FSK die Verbindung aufbauen. Die Connect-Grenze liegt bei etwa -10 dB (be-
zogen auf 4 kHz Noise-Bandbreite) beim PTC-I. Der PTC-II verwendet ein glei-
tendes Memory-ARQ bereits beim Einphasen. Er tauscht sozusagen Connect-Zeit
gegen Robustheit ein. Bei 4 Connectpaketen ergibt sich durch die Aufsum-
mierung ein "Gewinn" von 6 dB. (Wenn man es als "repetition coding" betrach-
tet, ist der Gewinn natürlich 0 dB, hi, siehe oben.)
Der PTC-II kann auch bei -16 dB @ 4 kHz noch einphasen, allerdings braucht
er dabei etwas länger.
>Was mich an Pactor-II und auch an Clover nervt, ist, daß die Hersteller sich
>die Funkamateure als Betatester einer neuen Technologie suchen, die Protokolle
>dort optimieren, um das ganze dann kommerziell auszuschlachten. An sich ist
>das noch nicht so verwerflich, aber da wichtige Informationen fehlen
>(insbesondere bei Pactor-II, Clover ist einigermaßen dokumentiert, allerdings
>nicht ausreichend, um es zu implementieren), benutzt man eine Blackbox und wird
>zum Versuchskaninchen.
>So habe ich mir experimentellen Funkdienst nicht vorgestellt. Insofern finde
>ich auch die diesjährige Verleihung des Horkheimer Preises an die Pactor-
>Entwickler problematisch. Für Pactor-I hätten sie diesen Preis schon vor
>Jahren verdient, für Pactor-II sicher nicht!
Finde ich sehr schade, was Alexander hier schreibt. Ähnliches muß ich mir
von verschiedenen Leuten auch auf Messen immer wieder anhören. 8-(((((
PACTOR-II habe ich ganz klar mit Hauptgewichtung auf den AMATEURFUNK ent-
wickelt. Was wollen Kommerzielle mit einem Mitlesemodus oder Pseudo-Markow-
Codierung für flotte Direkt-QSOs??
Daß diese Technologie auch von Kommerziellen eingesetzt wird, sehe ich mit
einer gewissen Genugtuung. Daß die Funkamateure irgendwie als "Versuchska-
ninchen" eingesetzt werden, halte ich für eine bösartige Unterstellung. Ich
verbringe bestimmt 20 mal so viel Zeit mit Fragen aus der AFU-Szene im Ver-
gleich zum kommerziellen Sektor. Was wollen Kommerzielle mit einem PR/PACTOR-
Gate oder FAX und SSTV in allen Spielarten?
Es gibt auch ein paar ganz einfache Gründe, weshalb ich das PACTOR-II-Proto-
koll noch nicht in allen Details veröffentlicht habe:
- Es ist ein sehr großer Aufwand, das Protokoll in eine Form zu bringen,
die für Dritte nachvollziehbar ist. Es handelt sich nicht nur um 10 Sei-
ten sondern um einen vollen Ordner.
Dies ist natürlich nicht der Hauptgrund. Meine Erfahrungen mit PACTOR-I bzw.
der kompletten Veröffentlichung des Protokolles waren äußerst schlecht.
Ich hatte sehr viel Zeit damit verbracht, die Privat-Implementierungen
des PACTOR-I-Protokolles bei einigen "OM" zu unterstützen. Der Dank:
PACTOR-I wurde kommerziell eingesetzt durch Leute, die unter dem Deck-
mantel des Amateur-Charakters Informationen und in Jahren erarbeitetes
Know-How erschlichen haben - leider auch in DL!
>Nebenbei: auch Pactor-II ist wahrscheinlich auf einem modernen PC mit
>Soundkarte zu implementieren (Thomas HB9JNX hat ja gerade so ziemlich alle
>KW-Modi einschließlich GTOR(!) unter Linux implementiert), aber ohne
>Spezifikation sicher nicht...
Dies ist eine Binsenweisheit: Irgendwann sind die Rechner auch mal so
schnell, daß sie einen kompletten Menschen emulieren können, hi.
Im Ernst: Auch falls in absehbarer Zeit ein Verfahren wie PACTOR-II auf
einem PC implementiert wird, sehe ich dennoch große Vorteile bei einem
Spezialcomputer für Datenübertragung, eben z. B. einem PTC-II.
- Wer will schon seinen "Desktop" mit EINEM Task, nämlich PACTOR-II, komplett
auslasten?
- Die Taktfrequenzen der PCs sind viel zu ungenau und schwanken oftmals
ganz erheblich. "Plug and Play" ist eine PC-Lösung für PACTOR-II bestimmt
nicht.
- Ohne zusätzliche PTT-Hardware kommt man eh nicht aus.
- Der PTC ist relativ klein, braucht wenig Strom und ist einfach ideal für
Portabelbetrieb - mal ganz abgesehen von der HF, die ein großer PC norma-
lerweise durch die Gegend schleudert.
***
Read previous mail | Read next mail
| |
