WSJT-X #
Problem von WSJT-X bei Nicht-Standard-Rufzeichen #
Während eures FT8-Betriebs wird es vorkommen, dass, wenn ihr das “lange” Eventrufzeichen (2024 -> DF4CEPALM) verwendet, ihr von anderen Nicht-Standard-Rufzeichen angerufen werdet.
Problem: Ein QSO mit zwei Nicht-Standard-Rufzeichen ist mit WSJT-X nicht möglich, da mit zwei solch langen Rufzeichen die Bits innerhalb einer WSJTX-Nachricht nicht ausreichen, um außerhalb der beiden Rufzeichen IRGEND eine andere Info mit durchzusenden. D.h. es wird immer nur der Rufzeichentausch generiert, Rapport oder Roger oder 73 wird nie gesendet werden, das wird einfach abgeschnitten.
So sieht sowas aus:
| Decode Nr. | Inhalt | Beschreibung |
|---|---|---|
| 0 | … | Ihr funkt so vor euch hin… |
| 1 | CQ DF4CEPALM JN49 | und ruft CQ… |
| 2 | <DF4CEPALM> PD33ZDOGE | Ein anderes nicht-Standard-Rufzeichen antwortet… |
| 3 | PD33ZDOGE <DF4CEPALM> | Euer WSJT-X versucht einen Rapport zu senden, es sind aber zu viele Bits… |
| 4 | <DF4CEPALM> PD33ZDOGE | Das WSJT-X eures QSO-Partners macht dasselbe … |
| 5 | PD33ZDOGE <DF4CEPALM> | Eures auch… |
| 6 | <DF4CEPALM> PD33ZDOGE | … und schon sind wir in einer Scheife… |
| 7 | … | … die so lang geht bis einer aufgibt. |
Das Ganze ist übrigens nicht nur bei Eventcalls so, sondern geht auch mit “DB4SCW/P”, “DB4SCW/QRP” nicht. All diese Stationen werden versuchen euch zu erreichen, werden aber leider an der Limitation des FT8-Protokolls scheitern.
Leider reagiert hier WSJT-X nicht mit einer Fehlermeldung die erklärt, warum das so ist, sondern (siehe Tabelle oben Decode 2-6) wird immer weiter fröhlich Quatsch produzieren und auch senden (!!!), solange bis ein OP (entweder der QSO-Partner oder ihr selbst) eingreift und abbrecht.