26.-27.08.2023
24 Stunden WW DIGI DX Contest sind vorüber…
Die Ausbreitungsbedingungen waren ziemlich gut – es wird Herbst, die Nächte werden länger und die Ionosphäre verändert sich zunehmend. 21 MHz war sehr lange offen, 14 MHz bis Mitternacht.
Obwohl 10m und 80m (160m ohnehin nicht) keine große Rolle spielten war FT-4 auf 20m und 15m sehr effizient und brachte zusammen den Großteil der QSO’s sein. Mit ca. 462 QSO’s* war ich am Ende doch sehr zufrieden – aber man merkt es schon am Sternchen – die Sache hat noch einen Haken …
Der “Haken” offenbahrte sich schon nach den ersten QSO om Contest. Ich weiß auch nicht, was genau mich dazu bewegte (sicherlich die Bequemlichkeit) – aber ich habe nicht wie gewohnt mit N1MM geloggt. Der erste Contest nach vielen Jahren ohne dem Komfort und der Sicherheit von N1MM… Ich dachte, ach – das schaffe ich auch mit “Bordmitteln” – heißt in meinem Fall WSJT-X. Das war ein wirklich schwerer Fehler. Aber man lernt ja aus solchen Dingen.
Mit WSJT-X allein ist ein Contest eigentlich unmöglich. Einmal gearbeitete Stationen werden (zumindest bei mir mit der Version 2.6.1) nicht ausgegraut – man erkennt also keine Dupes. Also nutzte ich JTAlert, was mir diesbezüglich einen Überblick gab. Allerdings tauchen hier im Alert-Window nicht alle Stationen auf, die man im Activity Window von WSJT-X sieht (mindestens ein Call feht immer).
Bitte macht niemals den Fehler und versucht das Contestlog von WSJT-X während des Contest zu editieren (z.B. Uhrzeit ändern) – dieses QSO ist für immer verloren. Ein schwerwiegender Bug …
Also verlies ich mich am Ende auf das von WSJT-X generierte ADIF File wsjtx_log.adi. Nach dem Contest musste ich allerdings feststellen, dass ich fast 12% Dupes hatte. Woher genau die kommen, muss ich noch untersuchen.
Ein digitaler Contest unterscheidet sich im Logging wesentlich von CW/SSB Contesten. Das macht am Ende wohl auch die wesentlich höhere “NIL” Rate bei diesen Contesten aus. Das Thema wurde schon breit diskutiert.
[https://wsjt.sourceforge.io/NCJ_FT4_FT8_Contesting.pdf]
Aber ein paar Gedanken seien mir erlaubt:
* Manche Stationen rufen zwar CQ WWW, scheinen aber nicht im Contest Mode von WSJT (oder ihrer Software zu sein) – somit gibt es Rapport Probleme, weil die Software einen dB Wert und nicht einen Locator erwartet.
* Manche Stationen rufen im empfohlenen Contestbereich CQ ohne wirklich im Contest teilzunehmen – Problem wie oben
* Manche Stationen rufen CQ WWDX, CQ DIGI, CQ TEST anstatt CQ WW – ok – das ist nicht schlimm 😉
* VIELE Stationen senden kein 73 am Ende des QSO
Zu diesem letzten Punkt möchte ich gerne ausholen, weil genau dies der Grund für manche hohe NIL Rate ist:
WSJT-X loggt ein QSO wenn man “RR73” sendet oder die Gegenstation ein “RR <Locator>” sendet. Damit steht die Station im Log. Wenn aber das RR73 nicht empfangen wurde und ein neuer (oder gar ein zweiter) Austausch nötig ist – steht die “falsche” Zeit im Log. Das kann manchmal ein Unterschied von bis zu 1.5 Minuten (FT-8) sein.
Welchen Zeitstempel wertet denn meine Software aus?
Der ADIF Standard ist hier recht großzügig. Wir haben hier einen <time_on>, einen <time_off> Stempel. Welcher wird benutzt, wenn man in Cabrillo konvertiert? In der Regel der <time_on> – was aber zu Problemen führt, wenn die Gegenstation mich nicht beim ersten Mal komplett aufgenommen hat und ein/zweimal nachfragen muss. Dann liegen die Zeitstempel unserer QSO auseinander.
Wenn kein “73” zurück kommt, steht das QSO zwar in meinem Log – aber vielleicht nicht im Log der Gegenstation – eine unklare Situation…
Also, um zu einem Ende zu kommen – ich werde in Zukunft nicht wieder den Fehler machen, mit WSJT-X einen Contest zu loggen. Punkt.
Ich bin gespannt, was am Ende herauskommt und werde natürlich berichten. Es war (trotzdem) ein schöner Contest mit guten Bedingungen (Richtung VK, ZL, VP8) und auch guter Aktivität (JA, YB, CE, LU, Europa sowieso).