WSJT-X - Amateurfunk-Station DK1IO

Erweiterung der Funktionalität eines existierenden Prograqmms am Beispiel von WSJT-X

Auf dieser Seite zeige wie ich ich WSJT-X an meine eigenen Anforderungen angepasst habe.
Diese Anforderungen sind:  
   Loggen in das eigene Log in einer SQLite-Datenbank
   Exportieren des QSO nach eQSL
   Überprüfen auf QSO B4 mit dem eigenen Log
   Ändern der Sendeleistung über CAT
Die Anpassung ist keine Änderung von WSJT-X, sondern ein autarkes Zusatzprogramm, das die gewünschte Funktionalität herstellt.
Die Schnittstelle zwischen WSJT-X und dem Zusatzprogramm bildet die Datei 'wsjtx_status.txt', die von WSJT-X bei jeder Änderung von QSO-Daten sofort aktualisiert wird.
Durch regelmäßige Abfrage der Datei erhält das Zusatzprogramm die Informationen für seine Aktionen.
Die Daten für das Loggen liefert die Datei 'wsjtx_log.adi', die von WSJT-X bei Klick auf den Log-Button im Log-Fenster entweder erstellt wird oder um die QSO-Daten erweitert wird.
Da das Zusatzprogramm aber nach dem Loggen diese Datei löscht, kommt eigentlich nur der erste Fall in Frage.
Wenn die Datei 'wsjtx_log.adi' existiert, wird das QSO in die eigene Datenbank geschrieben und nach eQSL exportiert.
Wenn über CAT auf den Transceiver zugegriffen werden soll, besteht das Problem, dass die serielle Schnittstelle schon von WSJT-X in Anspruch genommen ist und für eine andere Anwendung nicht zur Verfügung steht.
Umgekehrt, wenn das Zusatzprogramm zuerst den CommPort öffnet, kommt WSJT-X nicht zum Zuge und gibt eine Fehlermeldung aus.
Abhilfe schafft hier ein virtueller COM-Port. Näheres dazu steht auf der Seite 'RS232'.
Beim Programmstart wird vom Transceiver die Frequenz abgefragt und mittels einer Datenbanktabelle die für das jeweilige Band richtige JT65-Frequenz eingestellt.
Wenn nach Doppelklick auf eine Zeile im Fenster 'Band Activity' festgestellt wird, dass auf diesem Band und in dieser Betriebsart mit der Station schon ein QSO im Log steht, wird durch einen simulierten Klick auf 'Halt TX' der Anruf verhindert.
Habe ich CQ gerufen, wird selbstverständlich jeder Anruf beantwortet.
Ursprünglich waren die Zusatzelemente auf dem WSJTX-Fenster angeordnet. Da aber in der Version 1.8.0 der zur Verügung stehende Platz kleiner wurde, befinden sie sich jetzt in einem gesonderten Fenster, das rechts oben neben dem WSJTX-Fenster angeordnet ist.
Das obere Feld zeigt den Namen des QSO-Partners an, wenn er denn im Log vorhanden ist.
Bei den drei unteren Elementen handelt es um die Anzeige der Sendeleistung sowie die Buttons zum Erhöhen bzw. Verringern der Leistung.
Bei Klick auf die Buttons wird die Leistung verdoppelt bzw. halbiert in einem Breich von 1W bis 64W.
Wer auf die Änderung der Sendeleistung per CAT verzichtet, braucht dann auch keinen virtuellen COM-Port und kann WSJT-X den realen COM-Port zum Transceiver überlassen.
Und wer auch die Überprüfung auf QSO B4 nicht braucht, kann auf die verwendeten API-Funktionen verzichten. Dann sollte auch die Demoversion von PureBasic zur Erstellung eines ausführbaren Programms ausreichen.
Da ich den IC-7100 für meine Portabelaktivitäten nutze, habe ich in das Zusatzprogramm für diesen TRX die untenstehende Zeitsynchronisation eingebaut. Dafür entfällt das Exportieren nach eQSL, da ich portabel keinen Internetzugang habe.
Das folgende Bild zeigt WSJT-X mi dem Zusatzfenster in der Version für den IC-7100 (für Portabeleinsatz).
Der Button "KA" verhindert (bei roter Schrift) den Anruf von bereits gearbeiteten Stationen. Das macht nur Sinn, wenn diese Version ausnahmsweise mal zu Hause eingestzt wird.
Darunter wird die Zeit der letzten Synchronisation angezeigt. Und schließlich wird der aus der GPS-Position berechnete Locator angezeigt. Der muss manuell in WSJT-X eingegeben werden.

Bild 1


Der
Quellcode des Zusatzprogramms
kann von der Downloadseite heruntergeladen werden.

Zeitsynchronisation
Die Zeitdifferenz zwischen beiden Stationen soll max.  ±1 Sekunde betragen. An der Heimstation ist das Einhalten dieser Forderung kein Problem. Ein entsprechendes Programm (bei mir "Dimension 4") synchronisiert die PC-Uhr mit einem Internet-Zeitserver.
Ich möchte die WSJTX-Betriebsarten aber auch bei Portabelaktivitäten (SOTA) nutzten, bei denen ich keinen Internetzugang habe. Der Problemlöser ist ein GPS-Empfäger. Dieser gibt in dem NMEA-Datenstrom auch die Uhrzeit aus.
Ein Nachteil sei nicht verschwiegen. Wer ein Tablet oder Notebook mit nur einem USB-Anschluss hat, braucht zusätzlich einen USB-Hub, denn es müssen ja der Transceiver und der GPS-Empfänger angeschlossen werden.
Es gibt zwei Gruppen von GPS-Empfängern: mit und ohne PPS-Ausgang (PPS = Puls Per Second). Ich habe eine normale GPS-Maus ohne PPS mit USB-Anschluss erworben (Navilock NL-442U mit SiRF-Chipsatz). Nach Installation des zugehörigen Treibers erscheint im Gerätemanager ein Comm-Port mit der Bezeichnung Prolific. Nun kann man sich mit dem Programm "GPS-Information" den Datenstrom ansehen, den der GPS-RX an den Comm-Port sendet. Man erkennt, dass zwei Datensätze die Uhrzeit enthalten.

Bild 2


Ich verwende den Datensatz, der mit "$GPGGA" beginnt. Nach dem Komma beginnt die Uhrzeit mit Stunde, Minute und Sekunde, jeweils zweistellig. Wie wir sehen, wird dieser Datensatz immer zur vollen Sekunde gesendet. Das nutze ich aus, um die Uhr des Tablets zu synchronisieren.
Mit dem Ergebnis bin ich sehr zufrieden.
Bei dem Tablet handelt es sich  um das Modell CHUWI HiBook Pro mit 10" Display. Ich hatte anfänglich die Befürchtung, dass die Taktfrequenz von 1,44 GHz nicht ausreichen würde, dem ist aber nicht so.
Das Tablet verfügt über zwei USB-Anschlüsse: einen Mikro-USB-Anschluss und einen C-Anschluss. Der ist hauptsächlich zum Laden gedacht, kann aber auch für die Datenübertragung genutzt werden. Da das Transceiverkabel und das GPS-Kabel jeweils über USB-A-Stecker verfügen,
muss bei beiden ein Adapter zwischengeschaltet werden.
Die Verbindung zwischen GPS und Tablet ist nun keinesfalls eine Einbahnstraße. Es können auch Nachrichten in Richtung GPS geschickt werden, die dessen Verhalten beeinflussen. So habe ich z.B. die Übertragungsrate auf 9600 Bd geändert.
Der GPS kann im NMEA-Modus oder im SiRF Binary Modus betrieben werden. Wer Näheres erfahren möchte, gibt im Internet als Suchbegriff "SiRF NMEA" oder "SiRF Binary" ein. Für beide Fälle gibt es je ein Manual, in denen die Eingangs- und Ausgangsnachrichten erklärt werden.
Während im NMEA-Modus die Nachrichten als String gesendet werden, geschieht das im Binary Modus in Form von hexadezimalen Werten. In beiden Fällen ist eine Prüfsumme (Checksum) mitzusenden.
Ein kleines PureBasic-Programm übernimmt die Arbeit. Wichtig ist, dass in der PureBasic-Entwicklungsumgebug (IDE) unter "Compileroptionen" bei "Administratorrechte anfordern" ein Häkchen gesetzt wird. Das Ändern der Systemzeit nur mit Userrechten ist nämlich nicht möglich.

Für die Synchronisation habe ich zwei mögliche Lösungsansätze gefunden:

1. Der GPS-Empfänger wird in einen Zustand versetzt, in dem er periodisch zu jeder vollen Sekunde den $GPGGA-Datensatz ausgibt. Das
   Programm sucht den Anfang des nächsten Datensatzes, gekennzeichnet durch das "$"-Zeichen, und liest anschließend die Bytes, die
   die Zeit enthalten. Diese Werte werden in die PC-Uhr geschrieben, fertig. Die Zeit, die das Programm braucht, um "$" zu finden, liegt
   zwischen 0 Sek und 1 Sek und hängt vom Zeitpunkt des Programmstarts ab. Die Abweichung von GPS-Zeit und PC-Zeit kann bestimmt
   und durch Vorstellen der Uhr kmpensiert werden. Damit läuft die PC-Uhr synchron zur GPS-Zeit.
   Leider habe ich festgestellt, dass das Warten auf den nächsten Datensatz sporadisch mit WSJT-X kollidiert und WSJT-X die Meldung
   "Rig Control Error" ausgibt.

Bild 3       


2. Der GPS-Epfänger wird in einen Zustand versetzt, in dem er auf Anforderung den letzten gültigen $GPGGA-Datensatz einmalig ausgibt.
   Dieser wird ausgewrtet und die PC-Uhr gesetzt. Das Alter des Datensatzes (und damit der Uhrzeit) kann zwischen 0 Sek und 1 Sek
   liegen, abhängig vom Anforderungszeitpunkt. Hier ist also die Übereinstimmung zwischen GPS-Zeit und PC-Zeit nicht so gut, liegt aber
   immer innerhalb der Grenwerte. Es gibt auch keine Wartezeit, und WSJT-X hat keine Veranlassung, eine Fehlermeldung auszugeben.
   Wenn die PC-Uhr beim Setzen der Zeit um 500 ms vorgestellt wird, dann beträgt die maximale Abweichung nur ± 0,5 Sek. Im Durchschnitt
   wird sie deutlich besser sein. Wegen der Probleme bei Version 1 bevorzuge ich diese Version.
   In Bild 1 kann man sehen, dass die DT-Werte mit dieser Synchronisation ganz ordentlich sind.

Der GPS muss vor dem Start von WSJT-X in den Binary-Modus gesetzt werden und dann wieder zurück in den NMEA-Modus. Wieso das?
Weil der Befehl zum Zurücksetzen in den NMEA-Modus die Möglichkeit bietet, die sekündliche Ausgabe aler Datensätze zu sperren. Es soll ja nur
auf Anforderung ein Datensatz ausgegeben werden.
Das Hin- und Herschalten ist nur einmal nötig und wird im GPS dauerhaft abgespeichert.

Das Programm

Procedure GetGPSTime()
 PurgeComm_(hCOM_GPS, #PURGE_RXCLEAR)
 PurgeComm_(hCOM_GPS, #PURGE_TXCLEAR)
 SP$ = "$PSRF103,00,01,00,01*25" + #CR$ + #LF$
 WriteSerialPortString(#COM_GPS, SP$, #PB_Ascii)
 ReadSerialPortData(#COM_GPS, *CommBuf, 13)
 SP$ = PeekS(*CommBuf, 13, #PB_Ascii)
 GetSystemTime_(yST)
 yST\wHour = Val(Mid(SP$, 8, 2))
 yST\wMinute = Val(Mid(SP$, 10, 2))
 yST\wSecond = Val(Right(SP$, 2))
 yST\wMilliseconds = 500
 SetSystemTime_(yST)
EndProcedure

Die Prozedur GetGPSTime() wird einmalig beim Start von WSJT-X ausgeführt und dann timergesteuert im Abstand von z. Zt. 1 Min.
Zuerst werden Empfangs- und Sendepuffer gelöscht, dann wird die Anforderung des Datensatzes an den GPS geschickt.
Anschließend werden die ersten 13 Bytes dieses Datensatzes gelesen und in die Elemente der Strukturvariablen yST die entsprechenden Werte geschrieben.
Zum Schluss wird die PC-Zeit neu gesetzt.
Beim Kaltstart sollte man schon etwas Geduld aufbringen, denn es dauert einige Minuten, bis der GPS Tritt gefasst hat.