[A-DX] Relevanz: playlist im Programm von ROCK A.M. in RTTY / bessere Alternative?

[Roger]

Am 11.01.2020 um 07:53 schrieb Tom DF5JL:
> Roger,
>
> dazu kommt oft noch selektives Fading, was ein RTTY-Signal noch einmal
> stärker beeinträchtigt als ein FSK-Signal.

Hatte ich auch so geschrieben:
"........Wenn man bedenkt, das es noch zusätzlichen "Stress" durch
selektives
Fading und Multipath gäben könnte, dann sähe das Ergebnis in der
Realität für RTTY noch schlimmer aus......."


> Nur: Die QSO-Abwicklung ist bei RTTY direkter, schneller, durch die
> "Verschachtelung" (Interleave) und FEC-Funktionalität hinkt die
> Dekodierung dem Signal hinterher, also der andere OM hat bereits
> aufgehört zu senden, während deine Softwäre noch etwas Zeit benötigt,
> den Inhalt zu dekodieren. Das ist gerade bei Contesten eine ungünstige
> Eigenschaft.

Ja, gut alles einleuchtend.   Deshalb gibt es ja auch bei Audiocodes
(andere Geschichte, aber ähnliche Problematik) ganz spezielle mit sehr
geringer "Latenz":
https://feintech.eu/wofuer-braucht-man-aptx-bei-bluetooth-audio-uebertragungen
"......aptX Low Latency ist eine Weiterentwicklung und kommt zum
Einsatz, wenn Sender und Empfänger diesen Codec unterstützen. Die
Qualität ist die gleiche wie bei aptX, der zusätzliche Vorteil liegt
hier in der geringen Latenz. Mit Latenz bezeichnet man die Verzögerung,
die durch die Übertragung entsteht. Es dauert ein paar Millisekunden,
bis man den Ton vom Sender hört. Wenn jeweils Lautsprecher an Sender und
Empfänger sind, nimmt man dies als Hall oder Echo wahr. aptX Low Latency
begrenzt die Latenz auf 40 ms, dies ist auch der Wert der für
Audio-Video-Anwendungen empfohlen wird. Bei herkömmlicher Übertragung
mit SBC-Codec beträgt die Latenz 150 ms (+/- 50 ms). Wenn der Ton mit
SBC über Bluetooth übertragen wird, ist er nicht lippensynchron zum
Fernsehbild. Auch bei Computerspielen ist es irritierend, wenn die
Spielgeräusche verzögert übertragen werden. Daher eignet sich aptX Low
Latency optimal für zeitkritische Anwendungen wie Video, Gaming und
Musizieren. Wenn Sie hierbei Bluetooth einsetzen möchten, sollten Sie
prüfen ob beide Geräte diesen Standard unterstützen...."

oder hier:
"....Opus hat eine besonders niedrige Codec-Latenz, um bei
Echtzeit-Anwendungen in der Verarbeitung des typischerweise unmittelbar
vor der komprimierten Übertragung erzeugten Signales möglichst wenig
Verzögerung (Latenzzeit) zu verursachen. Opus arbeitet mit Blocklängen
von 2,5 bis 20 (60) ms mit dynamischem, artefaktfreiem Wechsel zwischen
unterschiedlichen Blocklängen...."


Wenn man allerdings als "Rundfunksender"  einen Datenblock sendet, dann
kommt es wohl auf irgendwelche Latenzen nicht an.
Besonders bei Übertragungen über Kurzwelle ist eine maximal mögliche
Verschachtelung in Zeit und Frequenz sinnvoll.
Hier hatte ich einmal  OLIVIA128-2K als persönlichen "Rekordhalter "
ermittelt.  Wenn der Datenstrom davor und dahinter perfekt war, dann
hatte OL128-2K  Dropouts  von bis zu 1800ms  ohne Datenverlust
überstanden. In einem anderen Fall reichte es aus, wenn nur 50% oder
weniger der AF-Bandbreite ungestört empfangen werden konnte.

Für ROCK A.M. wäre es also besser gewesen:
- die Daten in MFSK-32 zu senden  (deutlich robuster, doppelt so schnell
als RTTY)
- wenigstens bei dem RTTY eine RSID vorher zu senden   (  RTTY-Typ / 
RTTY-Mitten-Frequenz)
   In FLDIGI ist die Sende-RSID für RTTY standardmäßig NICHT aktiviert, 
deshalb wurde wahrscheinlich auch keine verwendet.
  Deshalb in meiner Collage der konkrete Hinweis darauf, das es so etwas
auch für RTTY (und CW!) gibt, und wo dies einzustellen wäre.
  Ich kenne von FLDIGI vielleicht nur  20% der gesamten Funktionalität. 
Das ist aber bestimmt schon deutlich mehr als die meisten anderen
FLDIGI-User kennen.     ;-)


roger