| |
DL8AAU > DSP 13.09.98 14:53l 102 Lines 5515 Bytes #-9674 (0) @ DL
BID : D98DB0AIS02E
Read: DF7ML DJ9KV LX2GT DJ2TK DL2NBU DC2MRR GUEST DK5RAS
Subj: re^3 PSK31 (vs. Pactor-II)
Path: DB0AAB<DB0ZKA<DB0LX<DB0CZ<DB0LJ<DB0ZDF<DB0AIS
Sent: 980913/1139z @:DB0AIS.#HES.DEU.EU [LBCM FFM JO40IC OP:DL3FDU] bcm1.40d
From: DL8AAU @ DB0AIS.#HES.DEU.EU (Alexander)
To: DSP @ DL
X-Info: No login password
DF7ML schrieb:
>Hallo dr Hansi ...
>
>verstehe eigentlich nicht,warum man sich mit psk31 ueberhaupt beschaeftigt,
>denn dieses Rad ist doch zum 2. Mal erfunden
>und kommt eigentlich 10jahre zu spaet...
>1990 waere es sicher noch interessant gewesen..
>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.
>Ausserdem kann man PSK-100 /200 /400 /800 (bit/sec) machen mit verschieden
>Frame-Laengen und alles in einstellbarer FEC-modeGUETE
>sodass die Fehlerrate beim Empfaenger gering bleiben
> ( Also genau 8 verschiedene PSK-modes + FEC hat der PTC-2 )
Dies wäre optional bei PSK-31 auch zu implementieren, allerdings nicht sonder-
lich sinnvoll. Der Trick ist, daß man die zur Fehlersicherung hinzugefügte
Redundanz wieder teilweise entfernt (Punktierung von Faltungscodes), wenn der
Kanal dies zuläßt. Das mag bei PACTOR-II sinnvoll sein, da es sich dort in
einem Geschwindigkeitszuwachs niederschlägt. Bei PSK-31 muß das Verfahren
lediglich so schnell sein, wie der OP tippen kann. Das ist aber wohl derzeit
gewährleistet.
>Hansi : nur bei allen PSK muss man bedenken,dass man nicht in einem LINK ist
> also eigentlich nur ein verbesserter RTTY (broadcast) Mode
> d.h. man weiss NIE, welche Fehler auf der anderen Seite
> entstanden sind !!
> der PTC-2 kann durch Redundanz-Schalter in FEC das alles zwar
> wesentlich verbessern !! Aber PGMme/Bilder lassen sich somit niemals
> fehlerfrei uebertragen...
> Vorteil ist wohl nur,dass man Broadcast macht und vielen OMs
> eine MSG somit senden kann....
Ja, das liegt daran, daß PSK-31 auch nicht für Filetransfer sondern fürs
QSO-machen entwickelt wurde.
> Darum bietet sich beim PTC-2 das auch an, dass man alles im festen
> und stabilen Link macht,der sogar bis -18dB unter dem Rauschen "hört"
> und plus "Memory-ARQ" alle errors restauriert
> ( da werden "bildlich gesehen,aus 10 def. AutoMotoren einer 100% erstellt
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
jetzt einfach). So etwas kann Clover - dort wird allerdings kein Faltungscode
verwendet, sondern ein Blockcode. Der ist vom Prinzip her schlechter geeignet.
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.
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!
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...
73' Alexander
Read previous mail | Read next mail
| |
