WSJT-X, Zeit-Synch - Amateurfunk-Station DK1IO

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

Auf dieser Seite zeige ich, wie 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
   Ändern der Sendeleistung über CAT
   Verhindern von Mehrfach-QSO
Die Anpassung ist keine Änderung von WSJT-X, sondern ein autarkes Zusatzprogramm, das die gewünschte Funktionalität herstellt.
Die Informationen für seine Aktionen erhält das Programm von den UDP-Nachrichten, die WSJT-X bei Anlass verschickt. In dem Originalcode für den UDP-Server wurde ein Thread verwendet. Wegen aufgetretener Probleme verwende ich einen einfachen Prozeduraufruf. Bisher läuft das Programm damit einwandfrei, so dass das die finale Lösung zu sein scheint. WSJT-X verschickt etliche Nachrichten, es wird jedoch nur die Status-Nachricht ausgewrtet. Mode, Frequenz und DX Call werden extrahiert und verarbeitet.
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 schaffen hier virtuelle COM-Ports. 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 FT8-Frequenz eingestellt.
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 beiden unteren Elementen handelt es um die Anzeigen der Sendeleistung sowie des Landes. Zwar bietet auch WSJT-X diese Funktion, dann wird das Fenster aber breiter, so dass für das Grafikdisplay nicht mehr genug Platz zur Verfügung steht.
Die Sendeleistung wird durch Drehen des Mausrades verändert. Dabei muss sich der Cursor im Fenster des Zusatzprogramms befinden.
Da ich kein leeres Stroh dreschen möchte, werden Mehrfach-QSOs auf dem selben Band und in der selben Betriebsart verhindert. Wenn das Log QSOB4 meldet, wird der Cursor auf den Button Halt TX gesetzt und ein Linksdklick simuliert. Dadurch wird ein Anruf verhindert.
Dieses Verhalten kann jedoch geändert werden. Durch Klicken auf das Feld für die Anzeiges des Landes wird dieses rot; jetzt kann jede Station angenommen werden. Das ist besonders sinnvoll bei eigenen CQ-Rufen.

Bild 1


Der
Quellcode des Zusatzprogramms
kann von der Downloadseite heruntergeladen werden.


Zeitsynchronisierung mit GPS

Wer WSJT-X portabel betreiben will, bekommt wegen der fehlenden Internetanbindung Probleme mi der Zeit. Abhilfe schafft hier ein GPS-Empfänger, der die genaue Zeit an den portablen PC überträgt.
Bei mir ist es ein Navilock NL-442U mit SiRF-Chipsatz. Mit Hilfe eines kleinen Programms wird auch für Portabelaktivitäten eine genaue Zeitanbindung erreicht. Das ist aber aauch für die Heimstation eine gute Alternative.
Bei Anschluss der GPS-Maus an einen USB-Port wird von Windows der Treiber automatisch installiert. Anschließend erscheint im Geräte-Manager ein neuer CommPort mit der Bezeichnung Prolific.
Bei Entfernen des USB-Steckers verschwindet der CommPort wieder.

Bild 2


Das Übertragungsverhalten des GPS wird für unsere Zwecke angepasst.
    1. Um mehr Zeit für die Datenverarbeitung zu erreichen, wird die Baudrate auf 38400 erhöht.
    2. Die Übertragung unterschiedlicher Datensätze wird auf einen reduziert. Dieser beginnt mit $GPGGA.
Dafür wird SiRF Demo benötigt. Dieses Programm habe ich bei SiRF-FALCOM heruntergeladen.
Nach Start von SiRF Demo auf dem Eingangsfenster OK klicken. Dann im Menü Action > Open Data Source , anschließend Action > Switch to SiRF-Protocol.
Jezt Action > Switch to NMEA-Protocol.
In dem jetzt geöffneten Fenster stellen wir die Parameter für unsere beiden Ziele ein.
    1. Rechts bei Baud rate  38400  auswählen
    2. In der Spalte links sind die versschiedenen Datensätze aufgeführt. Alle bis auf den obersten mit der Bezeichnung GGA auf 0 setzen.
Jetzt rechts oben auf den Button Send klicken.

Nun sollte das GPS für unsere Zwecke eingerichtet sein.
Beim erstmaligen Start des Programms erscheint ein Fenster, in das die CommPort-Nr. des GPS einzugeben ist.
Damit wird der CommPort geöffnet; das Programm geht dann in eine Endlosschleife, in der die Prozedur GPS_Time() aufgerufen wird. Diese ist das Herzstück des Programms.
Als erstes wird so lange gewartet, bis eine evtl. anstehende Datensatz-Übertragung beendet ist. Der nächste übertragene Datensatz wird dann für die Zeitsynchronisation ausgewertet. Wir beschränken uns auf die ersten 13 Zeichen. Der Rest der 76 übertragenen Zeichen beinhaltet die Positionsangabe, die uns in diesem Zusammenhang nicht interessiert. Die ersten 6 Bytey sind die Kennung des Datensatzes, $GPGGA. Byte 7 ist ein Komma, dann folgen je zwei Bytes für Stunde, Minute und Sekunde. Damit wird die Systemzeit gesetzt.
Da das Ändern der Systemzeit Administratorrechte erfordert, musste ich in den Compiler-Optionen in PureBasic dem entsprechend ein Häkchen setzen.
Nach dem Aufruf der Prozedur folgt eine Verzögerung, die dem Aktualisierungsintervall entspricht.
In der EXE-Datei ist dieses Intervall auf 1 Minute (= 60000 ms) festgelegt.
Wer die Kaufversion von PureBasic besitzt, kann das Programm in der Entwicklungsumgebung laufen lassen und sieht dann zu jeder Minute die ersten 13 Zeichen des Datensatzes.

Bild 3


Für Testzwecke ist es sinnvoll, die Verzögerungszeit kleiner zu machen, z. B. auf 3 Sekunden. Also die vorletzte Programmzeile ändern auf
Delay(3000).
Wie gut die Übereinstimmung von DT ist, zeigt folgendes Bild..

Bild 4


Der PureBasic Sourcecode

; GPS-Zeitsynchronisierung
; Version 190813
; DK1IO 2018-2019

EnableExplicit

Global hCOM_GPS
Global SP$
Global yST.SYSTEMTIME
Global *CommBuf = AllocateMemory(13)

If ReadFile(0, "GPS_Time.ini")
 Define COM$ = ReadString(0, #PB_Ascii)
Else
 OpenFile(0, "GPS_Time.ini")
 Define COM$ = InputRequester("COM-Port", "Die GPS-CommPort-Nr. eingeben:", "COM")
 WriteStringN(0, COM$)
EndIf
CloseFile(0)

Procedure GPS_Time()
 While AvailableSerialPortInput(0)
   PurgeComm_(hCOM_GPS, #PURGE_RXCLEAR)
   Delay(1)
 Wend
 ReadSerialPortData(0, *CommBuf, 13)
 SP$ = PeekS(*CommBuf, 13, #PB_Ascii)
 If SP$ = ""
   End
 EndIf
 Debug SP$
 FillMemory(*CommBuf, 13)
 GetSystemTime_(yST)
 yST\wHour = Val(Mid(SP$, 8, 2))
 yST\wMinute = Val(Mid(SP$, 10, 2))
 yST\wSecond= Val(Mid(SP$, 12, 2))
 yST\wMilliseconds = 1
 SetSystemTime_(yST)
EndProcedure

hCOM_GPS = OpenSerialPort(0, COM$, 38400, #PB_SerialPort_NoParity, 8, 1, #PB_SerialPort_NoHandshake, 128, 128)
If Not hCOM_GPS
 MessageRequester("Fehler", "Der GPS-CommPort (" + COM$ + ") konnte nicht geöffnet werden")
 End
EndIf

Repeat
 GPS_Time()
 Delay(60000)
ForEver

Nach Anschluss des GPS kann es schon mal eine Viertelstunde dauern, biis er Tritt gefasst hat. Man kann das daran erkennen, dass in WSJT-X keine dekodierten Zeilen angezeigt werden und dass die Signale über die Zeitlinien hinausreichen.. Die Uhr geht dann etwa 2,5 Sekunden vor.

Eine ausführbare EXE-Datei, compiliert mit dem 64 Bit-Compiler, kann von der Downloadseite heruntergeladen werden.
Da das Programm keine Bednutzeroberfläche hat, bietet es keine Möglichkeit für die Beendigung  durch Mausklick oder Tastendruck. Deshalb wird das Programm durch Abziehen des USB-Steckers beendet.
*CommBuf wird nach jedem Lesezyklus auf 0 gesetzt. Wenn *CommBuf im nächsten Lesezyklus nicht mit mit neuen GPS-Daten gefüllt wird, wenn also die Verbindung unterbrochen ist, wird das Programm beendet.
Es dauert also maximal 1 Minute, bis das Programm beendet wird.
Die abgefragte CommPort-Nr. wird in der Datei GPS_Time.ini abgespeichert und bei jedem Neustart automatisch geladen. Die Datei ist in dem Verzeichnis gespeichert, in dem das Programm läuft.
Sollte sich die CommPort-Nr. ändern, einfach nur die ini-Datei löschen.