JTDX und JT-Alert – ein Team

Von Matthias, DL3VCO

Dieser Beitrag beschreibt das Zusammenwirken beider Programme. Natürlich nur in der Konfiguration, wie ich sie benutze. Er ist und kann keine Bedienungsanleitung für JTDX oder JT-Alert sein!

Bei FT8 als zeitsynchrone Betriebsart beträgt die Zeit zwischen Empfang und Senden ca. 2 Sekunden. Während dieser kurzen Zeitspanne kann man keine manuelle Entscheidung zum Sendetext des nächsten Durchgangs treffen. Daher muss man schon vorm Ende des Empfangszyklus die möglichen Sendetexte parat haben, sonst kann man das vorgegebene Sende-/Empfangszeitraster nicht einhalten. Inzwischen ist FT8 so beliebt, das der Decoder auf manchen KW-Bändern nicht selten 20 QSOs und mehr pro Empfangsdurchgang ins RX-Fenster bringt. So ist es nahezu unmöglich geworden, innerhalb von ca. 2 Sekunden zu überblicken, welches der (20+) Calls nun welchen Status hat.

JTDX und JT-Alert als Gesamtbild
Bei so viel visuellen Input ist weniger mehr!

Schaut man sich die Anzahl der Stationen im JTDX-Wasserfall an und vergleicht diese mit der Anzahl der QSOs im JTDX-RX-Fenster, wird man feststellen, das dort weniger QSOs zu sehen sind! Und die Calls, die JT-Alert anzeigt, sind noch weniger!

Der Wasserfall zeigt sozusagen die „Rohdaten“ für den Decoder. Aus diesen „Rohdaten“ errechnet der Decoder das (ungefilterte) Empfangsergebnis. Dieses durchläuft die Filtereinstellungen von JTDX und dieses Ergebnis wiederum wird im RX-Fenster (von JTDX) dargestellt. Nur was im RX-Fenster auch zu sehen ist, kann an JT-Alert übermittelt werden. Hier durchläuft es die Filter von JT-Alert! Was man im RX-Fenster von JT-Alert sieht, ist das Ergebnis dieser „Reihenschaltung“ der Filter!

Filtereinstellungen JTDX

Die Settings von JTDX sind auf Grund ihrer Vielfalt in Sektionen unterteilt. Ich erläutere nur die Funktion der Filtereinstellungen, die für das Empfangsergebnis von Bedeutung sind. Ich bin für Tipps immer dankbar! Die violetten Texte in der Bildergalerie erläutern, was passiert, wenn man das entsprechende Häkchen setzt.

Settings ‚General‘ beeinflussen vor allen die Optik von JTDX
Sektion ‚Sequencing“: beeinflusst den zeitlichen Ablauf des QSO
Sektion ‚Reporting‘: beeinflusst das Verhalten beim Logging und bei der Kommunikation mit anderen Programmen
Sektion ‚Notifications‘: Welcher Call-Status wird überhaupt gefiltert und in welcher Farbe dargestellt.
Sektion ‚Filters‘: Kann man die Art der QSO eingrenzen, die man sehen möchte, z.B. nur CQ-Rufe
JT-Alert

Die Filter, die das Empfangsergebnis beeinflussen, sind bei JTDX nicht so sehr zahlreich. Daher können viele, nicht interessierende QSOs angezeigt werden. Jetzt kommt die Funktionalität von JT-Alert zum Einsatz. Die Filtereinstellmöglichkeiten dieses Programm sind dermaßen umfangreich, das man die Anzeige wirklich nach fast jedem QSO-Parameter filtern lassen kann. Die Bildergalerie lässt erahnen, was alles möglich ist!

Schnelle Alarm Ein-/Ausschalting
Einstellen der Prioritäten der Akarme
Die Möglichkeit, die ‚Ignored Callsign‘-Datenbank händisch zu bearbeiten
Orderpfad und Datei, wohin das (immer) nur letzte QSO geschrieben wird
Dieser File sollte immer aktuell sein, da JT-Alert diesen benutzt, um alle seine Statusauswertungen zu berechnen.
Wer mehrere Soundkarten zur Verfügung hat, kann hier die eintragen, die akustige Alarme machen soll.
Dekodierergebnis, in dem das eigene Call enthalten ist, leuchte in dieser Farbe auf
Steuert Verhalten von Alert, wenn man ein QSO loggt
Datenbank, die schon gearbeitete Calls enthält (‚B4‘), nicht händig zu bearbeiten
Eigenes Rufzeichen und Locator
Die Möglich keit, händisch Calls zu gesuchten Rufzeichen zu erklären oder diese aus der dDtenbank zu löschen
Wenn ein neues DXCC erkannt wird, leuchte dieses Rufzeichen in dieser Farbe auf
Wenn alle Filtereinstellungen stimmen, sollte man nur noch die Rufzeichen sehen, die einen selbst interessieren

Ein rechter Mausklick auf ein Rufzeichenkästchen, lässt ein (konfigurierbares) Pop-Up-Menü aufgehen, wo man z.B. direkt eine QRZ-Abfrage machen kann. Ist man bei QRZ eingeloggt, kann man suchen, ob man die QSL-Info findet. Im Ergebnis dieser Info kann man, wieder mit rechtem Mausklick, das Rufzeichen in die die ‚Wanted‘ oder ‚Ignored‘-Datenbank schicken. ‚Wanted‘-Rufzeichen verlieren diesen Status automatisch, wenn sie (später) geloggt werden. Mit der Möglichkeit, Calls in ‚Wanted‘ oder ‚Ignored‘ einzusortieren, kann man sich ein Call vormerken, was man später arbeiten möchte, wo aber im Moment kein Rankommen ist. Anderseits lässt sich aber auch eine Station in die „Ignored“-Datenbank eintragen, wenn kein Interesse an einem QSO besteht. Der Grund könnte z.B. sein, das von dieser Station keine QSL-Karte zu erwarten ist, da sie generell keine QSL schickt oder einen QSL-Weg bevorzugt, den man selbst nicht möchte. Ich benutze die ‚Ignored‘-Funktion, um Calls auszublenden, die keine QSL oder ausnahmslos elektronische verschicken. Mir ist (momentan) noch eine reale Karte lieber als ein Eintrag in einer Datenbank, die auf irgendeinen Server in der Welt liegt.

Dieser Beitrag soll nur (ansatzweise!!) zeigen , was mit der Kombination dieser 2 Programme möglich ist.

Nicht mehr und nicht weniger!

In diesem Sinne: 55 und AWDH in FT8 de Matthias, DL3VCO

PS: Bei Fragen bin ich unter dl3vco@gmx.de zu erreichen. Ein an die Mail angehängter Screenshot erklärt oft mehr als Worte!

JTDX und JT-Alert – ein Team