Author SHA1 Message Date
Marc Froehlich 6966edbfff manual update: map 2026-08-12 01:39:40 +02:00
Marc Froehlich 42d4b72dd6 website: prevent incomplete version-info deployments and regenerate validated update feeds after releases 2026-08-12 01:11:34 +02:00
Marc Froehlich 15f585c938 frequency-recognition: explicit frequencdies out of the name field will be copied to the qrg field and trigger the used band spot of a station to fit for this qrg. Airscout will then use this band explicitely for the calculation 2026-08-12 00:23:17 +02:00
Marc Froehlich 663f724c98 mapview: saved some space by moving some topics to the head bar 2026-08-11 23:38:47 +02:00
Marc Froehlich 9cccdb73e9 website - updated priority score md file 2026-08-10 03:13:18 +02:00
Marc Froehlich 401f271d56 fixed prio score penalty on sked fail 2026-08-10 03:06:06 +02:00
Marc Froehlich 00aefdacd5 website - updated macros md file 2026-08-10 02:53:03 +02:00
Marc Froehlich ea4fc9c008 website - updated dxcluster md file 2026-08-10 02:44:04 +02:00
Marc Froehlich caaeebd00c Added 6+4m and 10G and up frequency detection patterns 2026-08-10 02:42:29 +02:00
Marc Froehlich 852f76b05a fixed DXCluster Server where a spot will not be sent if no AP is between the station and me 2026-08-10 02:26:37 +02:00
Marc Froehlich d6c1ffbb34 website features and airscout information updated 2026-08-10 02:22:08 +02:00
Marc Froehlich cfbb978aee updated manual link and nav structure at the website 2026-08-10 02:08:11 +02:00
Marc Froehlich 8c3ff5f07c added favicon and finished the audit of the manual 2026-08-10 02:04:54 +02:00
Marc Froehlich 926bb9daee added manual (settings) and favicon for the website 2026-08-10 01:16:34 +02:00
Marc Froehlich 2828e7ef80 fix: make AirScout and map propagation band-aware by resolving realistic per-station QRGs to canonical AirScout bands, using one shared watchlist, honoring the operator-selected band for Calc selected and map path analysis, and replacing the obsolete 430 MHz fallback with 432 MHz (fixes #67) and parts of #74 2026-08-08 01:53:04 +02:00
Marc Froehlich b0cc5ee9ba updated en-manuals for skeds, user interface and features 2026-08-07 23:59:59 +02:00
67 changed files with 6618 additions and 723 deletions
+18 -2
View File
@@ -6,6 +6,7 @@ on:
- main
paths:
- "src/**"
- "packaging/icons/**"
- "pom.xml"
- "mvnw"
- "mvnw.cmd"
@@ -62,7 +63,16 @@ jobs:
shell: pwsh
run: |
New-Item -ItemType Directory -Force -Path dist | Out-Null
jpackage --type app-image --name praktiKST --input target/dist-libs --main-jar app.jar --main-class kst4contest.view.Kst4ContestApplication --module-path target/dist-libs --add-modules javafx.controls,javafx.graphics,javafx.fxml,javafx.web,javafx.media,java.sql,java.net.http,jdk.crypto.ec --dest dist
jpackage `
--type app-image `
--name praktiKST `
--icon packaging/icons/kst4contest.ico `
--input target/dist-libs `
--main-jar app.jar `
--main-class kst4contest.view.Kst4ContestApplication `
--module-path target/dist-libs `
--add-modules javafx.controls,javafx.graphics,javafx.fxml,javafx.web,javafx.media,java.sql,java.net.http,jdk.crypto.ec `
--dest dist
- name: Create Windows ZIP
shell: pwsh
@@ -113,6 +123,7 @@ jobs:
jpackage \
--type app-image \
--name KST4Contest \
--icon src/main/resources/icons/kst4contest.png \
--input target/dist-libs \
--main-jar app.jar \
--main-class kst4contest.view.Kst4ContestApplication \
@@ -198,6 +209,7 @@ jobs:
jpackage \
--type deb \
--name KST4Contest \
--icon src/main/resources/icons/kst4contest.png \
--input target/dist-libs \
--main-jar app.jar \
--main-class kst4contest.view.Kst4ContestApplication \
@@ -257,6 +269,7 @@ jobs:
jpackage \
--type rpm \
--name KST4Contest \
--icon src/main/resources/icons/kst4contest.png \
--input target/dist-libs \
--main-jar app.jar \
--main-class kst4contest.view.Kst4ContestApplication \
@@ -318,6 +331,7 @@ jobs:
jpackage \
--type app-image \
--name KST4Contest \
--icon src/main/resources/icons/kst4contest.png \
--input target/dist-libs \
--main-jar app.jar \
--main-class kst4contest.view.Kst4ContestApplication \
@@ -436,6 +450,7 @@ jobs:
jpackage \
--type app-image \
--name KST4Contest \
--icon src/main/resources/icons/kst4contest.png \
--input target/dist-libs \
--main-jar app.jar \
--main-class kst4contest.view.Kst4ContestApplication \
@@ -623,6 +638,7 @@ jobs:
jpackage \
--type dmg \
--name KST4Contest \
--icon packaging/icons/kst4contest.icns \
--input target/dist-libs \
--main-jar app.jar \
--main-class kst4contest.view.Kst4ContestApplication \
@@ -646,4 +662,4 @@ jobs:
with:
name: macos-dmg-${{ matrix.os }}
path: dist/KST4Contest-*-macos-*.dmg
retention-days: 14
retention-days: 14
+17 -2
View File
@@ -46,7 +46,16 @@ jobs:
shell: pwsh
run: |
New-Item -ItemType Directory -Force -Path dist | Out-Null
jpackage --type app-image --name praktiKST --input target/dist-libs --main-jar app.jar --main-class kst4contest.view.Kst4ContestApplication --module-path target/dist-libs --add-modules javafx.controls,javafx.graphics,javafx.fxml,javafx.web,javafx.media,java.sql,java.net.http,jdk.crypto.ec --dest dist
jpackage `
--type app-image `
--name praktiKST `
--icon packaging/icons/kst4contest.ico `
--input target/dist-libs `
--main-jar app.jar `
--main-class kst4contest.view.Kst4ContestApplication `
--module-path target/dist-libs `
--add-modules javafx.controls,javafx.graphics,javafx.fxml,javafx.web,javafx.media,java.sql,java.net.http,jdk.crypto.ec `
--dest dist
- name: Create Windows ZIP
shell: pwsh
@@ -90,6 +99,7 @@ jobs:
jpackage \
--type app-image \
--name KST4Contest \
--icon src/main/resources/icons/kst4contest.png \
--input target/dist-libs \
--main-jar app.jar \
--main-class kst4contest.view.Kst4ContestApplication \
@@ -168,6 +178,7 @@ jobs:
jpackage \
--type deb \
--name KST4Contest \
--icon src/main/resources/icons/kst4contest.png \
--input target/dist-libs \
--main-jar app.jar \
--main-class kst4contest.view.Kst4ContestApplication \
@@ -220,6 +231,7 @@ jobs:
jpackage \
--type rpm \
--name KST4Contest \
--icon src/main/resources/icons/kst4contest.png \
--input target/dist-libs \
--main-jar app.jar \
--main-class kst4contest.view.Kst4ContestApplication \
@@ -272,6 +284,7 @@ jobs:
jpackage \
--type app-image \
--name KST4Contest \
--icon src/main/resources/icons/kst4contest.png \
--input target/dist-libs \
--main-jar app.jar \
--main-class kst4contest.view.Kst4ContestApplication \
@@ -381,6 +394,7 @@ jobs:
jpackage \
--type app-image \
--name KST4Contest \
--icon src/main/resources/icons/kst4contest.png \
--input target/dist-libs \
--main-jar app.jar \
--main-class kst4contest.view.Kst4ContestApplication \
@@ -510,6 +524,7 @@ jobs:
jpackage \
--type dmg \
--name KST4Contest \
--icon packaging/icons/kst4contest.icns \
--input target/dist-libs \
--main-jar app.jar \
--main-class kst4contest.view.Kst4ContestApplication \
@@ -752,4 +767,4 @@ jobs:
release-assets/flatpakref/*.flatpakref,
release-assets/macos/KST4Contest-${{ github.ref_name }}-macos-*.dmg,
release-assets/docs/KST4Contest-${{ github.ref_name }}-manual-en.pdf,
release-assets/docs/KST4Contest-${{ github.ref_name }}-manual-de.pdf
release-assets/docs/KST4Contest-${{ github.ref_name }}-manual-de.pdf
+72 -16
View File
@@ -1,42 +1,98 @@
# KST4Contest
KST4Contest (also known as pratiKST) is a Java-based chat client for [ON4KST](http://www.on4kst.com/chat), focused on VHF/UHF/SHF contest operation.
KST4Contest is a Java-based client for the [ON4KST chat](https://www.on4kst.org/chat/login.php), developed for coordinated VHF, UHF and microwave contest operation.
## Website
The application is developed by Marc Fröhlich (DO5AMF) and since 2026 Philipp Wagner (DN9APW).
The offical Website of KST4Contest is now instead of [do5amf.funkerportal.de](https://do5amf.funkerportal.de) the new website [here](https://kst4contest.hamradioonline.de) [https://kst4contest.hamradioonline.de](https://kst4contest.hamradioonline.de)
## Start here
- [Project website](https://kst4contest.hamradioonline.de/)
- [Download Stable, Beta and Nightly builds](https://kst4contest.hamradioonline.de/download/)
- [Online manual](https://kst4contest.hamradioonline.de/manual/)
- [GitHub wiki](https://github.com/praktimarc/kst4contest/wiki)
- [Issues and bug reports](https://github.com/praktimarc/kst4contest/issues)
- [Development roadmap](https://kst4contest.hamradioonline.de/roadmap/)
## What KST4Contest does
KST4Contest combines the ON4KST chat with information that is useful when coordinating contacts during a contest.
Among other things, it can:
- display and filter stations from the supported ON4KST chat categories;
- derive band and frequency information from chat messages and station names;
- maintain Worked and NOT QRV information for the available bands;
- calculate station priorities from distance, activity and other available information;
- manage internal skeds and received Win-Test skeds;
- use AirScout information when evaluating possible aircraft-scatter contacts;
- display stations, paths and additional propagation information on maps;
- exchange information with supported logging programs, Win-Test, PSTRotator and a local DX Cluster interface;
- provide configurable automatic replies for recurring chat requests.
Calculated scores, aircraft-scatter information and path assessments are operating aids. They depend on the available data and should not be treated as guarantees that a contact is possible.
## Installation
Ready-to-use packages are available for Windows, Linux and macOS. These packages include the required Java runtime, so a separate Java installation is normally not necessary.
Use the central download page to select the appropriate build:
- **Stable** is intended for normal contest operation.
- **Beta** contains changes that are being prepared for a stable release.
- **Nightly** contains the latest automated development build and is mainly intended for testing.
[Open the download page](https://kst4contest.hamradioonline.de/download/)
## Documentation
The full user documentation is maintained in the project wiki:
The documentation is available in German and English:
- https://github.com/praktimarc/kst4contest/wiki
- [German manual](https://github.com/praktimarc/kst4contest/wiki/de-Home)
- [English manual](https://github.com/praktimarc/kst4contest/wiki/en-Home)
- [Online manual](https://kst4contest.hamradioonline.de/manual/)
Direct entry points:
The Markdown sources used for the wiki and the generated PDF manuals are stored in [`github_docs`](github_docs/).
- German start page: https://github.com/praktimarc/kst4contest/wiki/de-Home
- English start page: https://github.com/praktimarc/kst4contest/wiki/en-Home
Changes to operating behaviour should be documented together with their purpose and limitations. This is especially important for functions whose result depends on external data, heuristics or information derived from chat messages.
## Build
## Building from source
Compile locally with Maven Wrapper:
Building KST4Contest requires JDK 21. The Maven Wrapper included in the repository should be used, so a separate Maven installation is not required.
Linux and macOS:
```bash
./mvnw clean test
./mvnw -B -DskipTests compile
```
## Notes
Windows:
- Source code is under `src/`.
- Documentation markdown pages for wiki/PDF are under `github_docs/`.
```powershell
mvnw.cmd clean test
mvnw.cmd -B -DskipTests compile
```
## Status of the latest CI:
Wiki Publishing:
## Repository structure
- `src/main/java/` application source code
- `src/test/` automated tests
- `github_docs/` German and English manual sources
- `website/` project website sources
- `packaging/` platform-specific packaging files
## CI status
### Documentation
[![Publish wiki](https://github.com/praktimarc/kst4contest/actions/workflows/github-wiki.yml/badge.svg)](https://github.com/praktimarc/kst4contest/actions/workflows/github-wiki.yml)
[![Docs PDF](https://github.com/praktimarc/kst4contest/actions/workflows/docs-pdf.yml/badge.svg)](https://github.com/praktimarc/kst4contest/actions/workflows/docs-pdf.yml)
Builds:
### Builds
[![Nightly Runtime Artifacts](https://github.com/praktimarc/kst4contest/actions/workflows/nightly-artifacts.yml/badge.svg)](https://github.com/praktimarc/kst4contest/actions/workflows/nightly-artifacts.yml)
## License
KST4Contest is distributed under the [GNU General Public License v3.0](LICENSE).
+26 -6
View File
@@ -1,10 +1,13 @@
# KST4Contest
# KST4Contest Manual / Handbuch
KST4Contest is a desktop client for the [ON4KST Chat](https://www.on4kst.org/chat/login.php), developed for VHF, UHF and SHF contest operation. It combines chat, candidate selection, sked planning, aircraft scatter information and connections to logging and station software.
KST4Contest is a desktop client for the [ON4KST Chat](https://www.on4kst.org/chat/login.php), developed for VHF, UHF and SHF contest operation. It combines chat, candidate selection, sked planning, aircraft-scatter information, station mapping and connections to logging and station software.
KST4Contest ist ein Desktop-Client für den [ON4KST-Chat](https://www.on4kst.org/chat/login.php), der für den Contest-Betrieb auf den VHF-, UHF- und SHF-Bändern entwickelt wurde. Er verbindet Chat, Stationsauswahl, Sked-Planung, Aircraft-Scatter-Daten sowie die Anbindung an Log- und Stationssoftware.
KST4Contest ist ein Desktop-Client für den [ON4KST-Chat](https://www.on4kst.org/chat/login.php), der für den Contest-Betrieb auf den VHF-, UHF- und SHF-Bändern entwickelt wurde. Er verbindet Chat, Stationsauswahl, Sked-Planung, Aircraft-Scatter-Daten, Stationskarte sowie die Anbindung an Log- und Stationssoftware.
Developed by / Entwickelt von **DO5AMF (Marc Fröhlich)**, operator at / Operator bei DM5M.
Developed by / Entwickelt von:
- **DO5AMF (Marc Fröhlich)**, operator at / Operator bei **DM5M**
- **DN9APW (Philipp Wagner)**, developer since / Entwickler seit Mai 2025
---
@@ -14,12 +17,29 @@ Developed by / Entwickelt von **DO5AMF (Marc Fröhlich)**, operator at / Operato
|---|---|
| [Deutsches Handbuch](de-Home) | [English manual](en-Home) |
Both versions follow the same structure and describe the same application state.
Beide Sprachfassungen verwenden dieselbe Struktur und beschreiben denselben Programmstand.
---
## Start here / Hier beginnen
- [Download Stable, Beta or Nightly / Stable, Beta oder Nightly herunterladen](https://kst4contest.hamradioonline.de/download/)
- [Online manual / Online-Handbuch](https://kst4contest.hamradioonline.de/manual/)
- [Installation](de-Installation) / [Installation](en-Installation)
- [Configuration](en-Configuration) / [Konfiguration](de-Konfiguration)
The Stable version is the normal choice for contest operation. Beta and Nightly builds are intended for testing particular changes and may contain functions which have not yet been released as Stable.
Für den normalen Contestbetrieb ist die Stable-Version vorgesehen. Beta- und Nightly-Builds dienen dem gezielten Test neuer Änderungen und können Funktionen enthalten, die noch nicht als Stable veröffentlicht wurden.
---
## Project links / Projektlinks
- [Project website / Projektwebseite](https://kst4contest.hamradioonline.de/)
- [Download the current stable release / Aktuelle stabile Version herunterladen](https://github.com/praktimarc/kst4contest/releases/latest)
- [Downloads](https://kst4contest.hamradioonline.de/download/)
- [Source code / Quellcode](https://github.com/praktimarc/kst4contest)
- [GitHub Releases](https://github.com/praktimarc/kst4contest/releases)
- [Bug reports and feature requests / Fehler und Funktionswünsche](https://github.com/praktimarc/kst4contest/issues)
- [Online manual / Online-Handbuch](https://kst4contest.hamradioonline.de/manual/)
- [Development roadmap / Entwicklungsstand](https://kst4contest.hamradioonline.de/roadmap/)
Binary file not shown.

After

Width:  |  Height:  |  Size: 49 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 86 KiB

+100 -6
View File
@@ -177,24 +177,118 @@ Herleitung und Grenzen: [Prioritätsscore und Prioritätsliste](de-Funktionen#pr
---
## Cluster & QSO der anderen
## Stationskarte
Separates Fenster (kann miniaturisiert werden). Zeigt den Kommunikationsfluss zwischen anderen Stationen interessant in ruhigeren Phasen.
Die Stationskarte kann auf zwei Wegen geöffnet werden:
- **Windows → Show / hide station map** öffnet oder schließt das Kartenfenster.
- **Show on map** im **Further Info**-Bereich öffnet die Karte und zentriert sie auf die ausgewählte Station.
Die Karte zeigt die Stationen, die auch nach Anwendung der aktuellen Benutzerlistenfilter noch sichtbar sind. Ein Hinweis in der Kopfzeile zeigt an, wenn eine gefilterte Ansicht aktiv ist.
![Stationskarte mit ausgewählter Station und eingeblendeter Streckenanalyse](station_map_path_analysis.png)
Ein einzelner Stationsmarker kann direkt angeklickt werden. KST4Contest übernimmt die Station daraufhin als aktuelle Auswahl, scrollt die Benutzerliste zum passenden Chatmember und aktualisiert den **Further Info**-Bereich.
Marker, die bei der aktuellen Zoomstufe zu dicht beieinanderliegen, werden als Cluster mit einer Stationsanzahl angezeigt. Ein Klick auf einen Cluster vergrößert den betreffenden Kartenausschnitt. Erst ein anschließend sichtbarer einzelner Marker wählt eine konkrete Station aus.
Für die ausgewählte Station erscheinen rechts unter **Selected station**:
- Rufzeichen,
- Locator,
- QRB und QTF,
- erkannte aktive Bänder,
- gegebenenfalls `B+` für eine offene Bandmöglichkeit und
- die zuletzt bekannten QRGs.
**Trigger cluster spot** sendet für die ausgewählte Station einen einzelnen Spot an die mit dem integrierten DX-Cluster-Server verbundenen Logprogramme. Die Schaltfläche setzt deshalb einen aktivierten Cluster-Server und mindestens einen verbundenen Client voraus.
Unterhalb der Karte befindet sich das Höhenprofil. Rechts werden die dazugehörigen Detailwerte angezeigt, unter anderem:
- verwendete Datenquelle und Anzahl der Höhenpunkte,
- Analysefrequenz,
- Erdkrümmungs- beziehungsweise Refraktionsmodell,
- Radio- und Geländehorizont,
- Fresnel-Freiheit,
- erkannte Hindernisse,
- Link-Budget,
- geschätzter Empfangspegel und
- eine zusammenfassende Pfadbewertung.
Mit **Hide path analysis** werden das Profil unterhalb der Karte und die ausführlichen Analysewerte rechts gemeinsam ausgeblendet. Der Kartenbereich erhält dadurch mehr Platz.
![Stationskarte mit ausgeblendeter Pfadanalyse](station_map_compact.png)
Der Hinweis **Path analysis is hidden** bleibt zusammen mit **Show path analysis** sichtbar. Die Funktion kann daher ohne Umweg wieder eingeschaltet werden. Der Zustand wird gespeichert.
Der Divider zwischen Karte und Detailbereich lässt sich horizontal verschieben. Bei schmalem Detailbereich werden längere Angaben umgebrochen; falls die Höhe nicht ausreicht, erscheint dort eine vertikale Scrollleiste.
Ausführliche Herleitung und Grenzen: [Stationskarte und Streckenanalyse](de-Funktionen#stationskarte-und-streckenanalyse-ab-v141)
---
## Globale Nachrichtentabs und Monitorfenster
Der untere Bereich des Hauptfensters enthält drei globale Nachrichtentabs. Ihr Inhalt ist nicht von der aktuell in der Benutzerliste ausgewählten Station abhängig.
| Tab | Inhalt |
|---|---|
| **Public messages** | Öffentliche Chatnachrichten, CQ-Rufe und Beacons |
| **DXCluster messages** | Über ON4KST empfangene DX-Cluster-Meldungen |
| **QSO of the other** | Gerichtete Nachrichten zwischen zwei anderen Stationen |
![Globale Nachrichtentabs im Hauptfenster](global_message_tabs.png)
Im Tab **QSO of the other** werden Absender und Empfänger getrennt dargestellt. Die Spalten **Last QRG TX** und **Last QRG RX** enthalten die zuletzt für beide Stationen bekannten Frequenzen. Sie geben nicht zwingend die QRG der angezeigten Unterhaltung wieder.
**wkd TX?** und **wkd RX?** zeigen den globalen Worked-Status der beiden Basisrufzeichen. Die Angaben sind nicht bandbezogen.
Der Tab **DXCluster messages** zeigt den meldenden und den gemeldeten Teilnehmer, deren Locator, die QRG, den Meldungstext und den globalen Worked-Status der gemeldeten Station. Welche Felder tatsächlich gefüllt sind, hängt von der vom ON4KST-Server übertragenen Meldung ab.
Nachrichtentexte bleiben einzeilig. Ist eine Zelle zu schmal, erscheint der vollständige Inhalt als Tooltip. Webadressen im Meldungstext lassen sich anklicken.
### Separates Monitorfenster
Zusätzlich öffnet KST4Contest das Fenster **Cluster & QSO of the other**. Es zeigt oben die DX-Cluster-Meldungen und darunter die gerichteten Nachrichten zwischen anderen Stationen.
![Separates Cluster- und QSO-Monitorfenster](cluster_qso_monitor.png)
Die Position des vertikalen Dividers sowie die Fenstergröße werden zusammen mit den übrigen UI-Einstellungen gespeichert. Nach einer Änderung **Save Settings** verwenden.
Das Fenster lässt sich über das Menü aus- und wieder einblenden:
```text
Windows → Hide cluster / stranger QSOs
Windows → Show cluster / stranger QSOs
```
Die Tabellen im Hauptfenster und im Monitorfenster greifen auf dieselben Daten zu. Das Ausblenden des Monitorfensters beendet daher weder den Empfang noch die Darstellung in den unteren Tabs.
Herleitung und Grenzen: [Globale Nachrichtenansichten](de-Funktionen#globale-nachrichtenansichten).
---
## Menü
### Window
- **Use Dark Mode** (ab v1.26): Dunkles Farbschema aktivieren/deaktivieren.
### Windows
- **Hide cluster / stranger QSOs** beziehungsweise **Show cluster / stranger QSOs**: Blendet das zusätzliche Cluster- und QSO-Monitorfenster aus oder wieder ein.
- **hide options** beziehungsweise **show options**: Blendet das Einstellungsfenster aus oder wieder ein.
- **Use dark mode design**: Aktiviert das dunkle Farbschema.
- **Use default mode design**: Aktiviert das normale helle Farbschema.
- **Show / hide station map** öffnet beziehungsweise schließt das separate Fenster mit Stationskarte und Streckenanalyse.
---
## Fenstergrößen und Divider
Ab **v1.21** werden beim Klick auf **Save Settings"** auch Fenstergrößen und Divider-Positionen aller Panels in der Konfigurationsdatei gespeichert und beim nächsten Start wiederhergestellt.
Beim Klick auf **Save Settings** speichert KST4Contest die Größen der Programmfenster und die Positionen der relevanten Divider in der Konfigurationsdatei. Diese Werte werden beim nächsten Programmstart wiederverwendet.
Bei Problemen mit der Darstellung: Konfigurationsdatei löschen → KST4Contest erstellt neue Standardwerte.
Das Hauptfenster wird beim Start zusätzlich gegen den sichtbaren Bereich des primären Bildschirms geprüft. Ist die gespeicherte Größe zu groß, verkleinert und verschiebt KST4Contest das Fenster so, dass es wieder erreichbar bleibt. Die genaue Herleitung ist unter [Bildschirmgerechte Größe des Hauptfensters](de-Funktionen#bildschirmgerechte-größe-des-hauptfensters-ab-v141) beschrieben.
Für die übrigen Programmfenster gilt diese zusätzliche Größenbegrenzung derzeit nicht. Wird beispielsweise das separate Monitorfenster nach einem Wechsel auf einen kleineren Bildschirm zu groß dargestellt, muss seine Größe manuell korrigiert und anschließend erneut mit **Save Settings** gespeichert werden.
Bei einer ungünstigen Aufteilung sollten zuerst die Divider an eine brauchbare Position verschoben und die Einstellungen erneut gespeichert werden. Das Löschen der Konfigurationsdatei setzt zwar die UI-Werte zurück, entfernt aber auch die übrigen gespeicherten Programmeinstellungen und sollte deshalb nur verwendet werden, wenn sich die Oberfläche auf anderem Weg nicht mehr herstellen lässt.
---
+156 -13
View File
@@ -4,25 +4,168 @@
Versionsverlauf von KST4Contest / PraktiKST.
Die veröffentlichten Stable-Versionen und ihre Programmpakete stehen unter [GitHub Releases](https://github.com/praktimarc/kst4contest/releases). Zusätzlich enthält diese Seite die Änderungen des aktuellen Entwicklungsstands, soweit sie bereits implementiert und geprüft wurden.
---
letzter Changelog bitte aus GitHub entnehmen. Der bisherige Changelog
## v1.42 Nightly / in Entwicklung
## v1.42 (2026-08)
- **QRG-Erkennung präzisiert**: Vollständige und relative Frequenzangaben werden weiterhin erkannt. Nackte dreistellige Zahlen werden nur noch mit erkennbarem Frequenzkontext ausgewertet, damit Signalrapporte, Bandangaben und andere Zahlen keine falsche QRG erzeugen.
- **Stationsbezogener Bandkontext**: Bei relativen Frequenzen verwendet KST4Contest zuerst einen höchstens 30 Minuten alten Bandkontext desselben Absenders. Erst danach greift das globale Fallback-Band.
- **Fallback-Band als Dropdown**: Das globale Fallback kann nur noch aus den tatsächlich unterstützten Bändern ausgewählt werden und gilt für die gesamte QRG-Erkennung, nicht nur für DX-Cluster-Spots.
- **QRG-Anzeige vereinheitlicht**: Frequenzen werden in der Benutzerliste und den Nachrichtentabellen mit mindestens drei Nachkommastellen dargestellt.
> Stand dieses Abschnitts: 10. August 2026.
> v1.42 ist noch kein veröffentlichtes Stable-Release. Bis zur Freigabe können weitere Änderungen hinzukommen.
## v1.41
**Stationskarte, Performance, Reaktionsfähiges UI**
v1.42 führt mehrere bisher getrennte Auswertungen zusammen. Bandinformationen, Worked-Status, NOT-QRV-Markierungen, Rufzeichensuffixe und Frequenzen werden dadurch konsistenter in der Benutzerliste, der Stationskarte, der Prioritätsberechnung und den externen Schnittstellen verwendet.
**Neu:**
- **Stationskarte**: Interaktive OpenStreetMap-Karte zeigt die geografische Position aller aktiven Chatmember. Enthält Stationsmarker, Antennen-Kegel, Verbindungslinie zur ausgewählten Station, Maidenhead-Raster-Overlay und ein Wegprofil-Diagramm mit Geländehöhen-Analyse (Fresnel-Zonen, Horizonterkennung). Geländedaten aus Copernicus GLO-30, Open-Meteo API oder Offline-DEM-Import. Aircraft-Scatter-Weganalyse integriert. Funktioniert in AppImage und Flatpak ohne externe CDN-Verbindung (lokaler Tile-Proxy, eingebettetes Leaflet.js).
### Neu
**Geändert:**
- **Nachrichten-Tabellen-Limit auf 30.000 erhöht**: Chat- und Nachrichtentabellen sind auf 30.000 Einträge begrenzt. Ältere Nachrichten werden automatisch verworfen, was die Performance bei mehrtägigem Contest-Betrieb stabil hält.
- **Bildschirmgerechte Fenstergröße**: Beim Start wird das Hauptfenster auf den aktuellen Bildschirm angepasst. Wenn KST4Contest zuletzt auf einem größeren Monitor betrieben wurde, wird das Fenster automatisch verkleinert. Das UI-Layout ist kompakter und reaktionsfähiger auf kleineren Bildschirmen.
- **Gemeinsame Herleitung verfügbarer Bänder:** Ein zentraler `BandOpportunityResolver` wertet aktuelle QRGs, Bandangaben im Namensfeld, aktive Rufzeichenvarianten, Worked-Informationen und NOT-QRV-Markierungen gemeinsam aus. Benutzerliste, **New bands**, Band-Upgrade-Hinweis, Priority Score, Stationskarte und automatische Bandauswahl verwenden damit dieselbe Grundlage.
- **Erweiterte Bandanzeige:** Die Bandspalten unterscheiden jetzt:
- `X` für auf diesem Band gearbeitet,
- `a` für ein angebotenes, noch nicht gearbeitetes Band einer insgesamt neuen Station,
- `B+` für ein angebotenes, noch nicht gearbeitetes Band einer bereits auf einem anderen Band gearbeiteten Station und
- `o` für ein auf diesem Band bereits gearbeitetes Locator-Großfeld.
Die Anzeigen können kombiniert werden, beispielsweise als `ao` oder `B+o`. Die zusätzlichen Kennzeichnungen `a` und `o` lassen sich in den GUI-Einstellungen separat ausblenden.
- **Unterstützung für 50 und 70 MHz:** Beide Bänder stehen in der Stationskonfiguration, den Worked- und NOT-QRV-Funktionen, der Benutzerliste, den Filtern, der internen Datenbank, der UCXLog-Auswertung und dem Win-Test-Listener zur Verfügung. Bereits gespeicherte Datenbanken werden um die benötigten Spalten ergänzt.
- **Globale Nachrichtentabs:** Öffentliche Nachrichten, ON4KST-DX-Cluster-Meldungen und gerichtete Nachrichten zwischen anderen Stationen können direkt im Hauptfenster angezeigt werden. Das bisherige separate Monitorfenster bleibt zusätzlich verfügbar und verwendet dieselben Nachrichtenspeicher.
- **Manuelle QTF-Eingabe:** Die aktuelle Antennenrichtung kann auch ohne PSTRotator direkt in KST4Contest geändert werden.
- **Filter zurücksetzen:** Ein eigener Reset-Button entfernt die aktiven Filterprädikate der Benutzerliste zuverlässig.
- **Kartencluster:** Räumlich dicht beieinanderliegende Stationen werden bei niedrigen Zoomstufen zusammengefasst. Die ausgewählte Station und relevante Richtungsgelegenheiten bleiben einzeln sichtbar.
- **Ausblendbare Streckenanalyse:** Geländeprofil und Analysebereich der Stationskarte können vollständig ausgeblendet werden. Die Auswahl wird gespeichert und beim nächsten Programmstart wiederhergestellt.
### Geändert
- **QRG-Erkennung präzisiert:** Vollständige und relative Frequenzangaben werden weiterhin erkannt. Nackte dreistellige Zahlen gelten nur noch bei erkennbarem Frequenzkontext als QRG. Signalrapporte, Bandangaben und andere Zahlen erzeugen dadurch seltener falsche Frequenzen.
- **Stationsbezogener Frequenzkontext:** Bei relativen QRGs verwendet KST4Contest zuerst einen höchstens 30 Minuten alten Bandkontext derselben Station. Erst wenn dieser fehlt, wird das global konfigurierte Fallback-Band verwendet.
- **Fallback-Band als Dropdown:** Das globale Fallback kann nur noch aus unterstützten Bandwerten ausgewählt werden. Es betrifft die gesamte QRG-Erkennung und nicht nur DX-Cluster-Spots.
- **Einheitliche QRG-Darstellung:** Frequenzen werden in Benutzer- und Nachrichtentabellen mit mindestens drei Nachkommastellen dargestellt.
- **Bandabhängige AirScout- und Streckenberechnung:** KST4Contest leitet für jede Station eine möglichst realistische Frequenz aus der aktuellen QRG und den bekannten Bandinformationen ab. AirScout erhält kanonische Bandwerte. Die frühere Zwischenlösung mit 430 MHz wurde durch 432 MHz ersetzt.
- **Gemeinsame Frequenzherleitung:** AirScout, **Calc selected** und die Pfadanalyse der Stationskarte verwenden denselben `PropagationFrequencyResolver`. Ein im Reachability-Dropdown ausdrücklich gewähltes Band wird bei manuellen Berechnungen berücksichtigt.
- **Rufzeichenvarianten getrennt verarbeitet:** Aktive Chatmember werden durch das vollständige Rufzeichen einschließlich Suffix und die Chat-Kategorie unterschieden. `DN9APW`, `DN9APW-2` oder vergleichbare Logins bleiben dadurch getrennte Nachrichtenziele.
- **Gemeinsame Basisinformationen:** Worked-Flags, NOT-QRV-Informationen und der Priority Score werden weiterhin für Varianten desselben Basisrufzeichens gemeinsam ausgewertet. Getrennte Nachrichtenziele führen damit nicht zu widersprüchlichen Worked-Daten.
- **Priority Score korrigiert:** Stationen ohne gemeinsames verfügbares Band oder mit übersteuernder NOT-QRV-Markierung werden nicht mehr als Prioritätskandidaten angeboten. Bandgelegenheiten bereits gearbeiteter Stationen können einen eigenen Priority Boost erhalten.
- **Sked-Erstellung erweitert:** Das Band wird aus den lokal aktivierten Bändern gewählt. Für die Win-Test-Übergabe wird `SSB` oder `CW` ausdrücklich ausgewählt, statt den Mode unzuverlässig aus dem Band abzuleiten.
- **Win-Test-Sked-Übergabe präzisiert:** Die QRG muss zum gewählten Band passen. Sichtbare KST-Suffixe werden für das Logziel entfernt, portable Bestandteile bleiben erhalten und die Zeitangaben der `ADDSKED`-Pakete werden korrekt erzeugt. Ein Fehler bei der Übergabe entfernt den internen KST4Contest-Sked nicht.
- **Exakte Sked-Ziele:** Timeline und automatische Erinnerungen verwenden das vollständige sichtbare KST-Rufzeichen. Ein Sked für `DN9APW-2` wird nicht versehentlich an eine andere Variante desselben Basisrufzeichens gesendet.
- **Beacon und Autoantwort überarbeitet:** Beide Chat-Kategorien verwenden einen gemeinsamen Timer, behalten aber getrennte Aktivierungsschalter und Texte. Das zulässige Mindestintervall beträgt zwei Minuten; Nachrichtentexte sind auf 120 Zeichen begrenzt. Die gespeicherte Beacon-Aktivierung wird beim Start aus der Konfiguration übernommen.
- **Variablen zentral aufgelöst:** Nachrichtenvariablen für Beacons, Shortcuts, Snippets und andere automatisch erzeugte Texte werden über einen gemeinsamen Resolver verarbeitet.
- **Nachrichtentabellen verbessert:** Abgeschnittene Nachrichtentexte erhalten einen Tooltip mit dem vollständigen Inhalt. Erkannte Webadressen können im Systembrowser geöffnet werden.
- **Kompaktere Filterleiste:** Die Filter bleiben bei normaler Breite in einer kompakten Anordnung und werden erst dann umgebrochen, wenn der tatsächlich verfügbare Platz nicht mehr ausreicht. Der mittlere Divider kann dadurch weiter verschoben werden.
- **DXLog-Gesamtlog übernommen:** Der UCXLog-kompatible UDP-Listener verarbeitet neben `contactinfo` auch `contactreplace`. Dadurch kann ein von DXLog.net als vollständiges Log ausgesendeter Datenbestand eingelesen werden.
- **Versionserkennung verbessert:** Versionsnummern werden semantisch verglichen, damit beispielsweise Patch-Versionen und Nightly-Stände nicht mehr durch eine einfache Fließkommazahl falsch eingeordnet werden.
### Behoben
- **Langzeitfehler der Stationsauswahl:** Die vom Message-Thread verwalteten Chatmember wurden von der JavaFX-Ansicht entkoppelt. Gleichzeitige Änderungen der Daten und Tabellenansicht führen dadurch nicht mehr nach längerer Laufzeit zu fehlerhaften Auswahlmodellen oder Concurrent-Modification-Problemen.
- **Keine Phantom-Chatmember durch UM3:** Historische oder zusätzliche Servermeldungen erzeugen keine Benutzerlisteneinträge für Stationen, die nicht tatsächlich im Chat angemeldet sind.
- **Nachrichten an Rufzeichen mit Suffix:** Mehrere gleichzeitig angemeldete Varianten desselben Basisrufzeichens überschreiben sich nicht mehr gegenseitig. Damit wurde [Issue #73](https://github.com/praktimarc/kst4contest/issues/73) behoben.
- **DX-Cluster-Locatoren:** Sender und gemeldete Station erhalten nicht mehr versehentlich denselben Locator. Damit wurde [Issue #48](https://github.com/praktimarc/kst4contest/issues/48) behoben.
- **Worked-Anzeige in „QSO of the other“:** Die Worked-Spalten verwenden wieder die jeweils richtige sendende beziehungsweise empfangende Station.
- **Fehlende SECONDAP-Daten:** Eine nicht vorhandene zweite Aircraft-Scatter-Gelegenheit führt beim Bearbeiten der Anzeige nicht mehr zu einer ungültigen Textauswahl und JavaFX-Exception.
- **Historische Rufzeichen:** Das Hervorheben oder Anklicken eines Rufzeichens, das nicht mehr in der aktuellen Benutzerliste vorhanden ist, läuft nicht mehr in eine Exception.
- **Win-Test-Sked-Zeit und Rufzeichen:** Zeitstempel, Band-QRG-Zuordnung sowie die Behandlung von KST-Suffixen und portablen Rufzeichen wurden korrigiert.
- **Filter-Reset:** Alle Filterprädikate werden tatsächlich entfernt; der sichtbare Zustand des Buttons entspricht wieder dem wirksamen Filterzustand.
### Dokumentation und Auslieferung
- Das deutsche und englische Handbuch wurde systematisch mit dem Quellcode abgeglichen, erweitert und mit aktuellen Screenshots versehen. Die Dokumentation erklärt nicht nur die Bedienelemente, sondern auch Herleitung, Datenquellen und Grenzen der Funktionen.
- Für Arch Linux stehen `kst4contest-bin`, `kst4contest` und `kst4contest-git` im AUR zur Verfügung.
- Die Downloadseite unterscheidet Stable, Beta und Nightly und bietet die jeweils tatsächlich vorhandenen Pakete für Windows, Linux und macOS an.
- Nightly-Pakete werden automatisiert aus dem aktuellen `main`-Branch gebaut. Stable- und Beta-Releases verwenden reproduzierbare Paketnamen für die unterstützten Plattformen.
### Bekannte Grenzen
- Die aktive Geländedatenquelle verwendet Open-Meteo mit Copernicus-GLO-90-Daten und höchstens 100 Höhenpunkten pro Strecke.
- Der atmosphärische K-Faktor ist derzeit fest auf `4/3` eingestellt.
- Für die Gegenstation wird eine Antennenhöhe von 10 Metern über Grund angenommen.
- Aircraft-Scatter-Daten aus AirScout und die Geländeanalyse der Stationskarte sind weiterhin getrennte Bewertungen.
- Eine genauere Konfiguration von Stationshöhe, Frequenz und K-Faktor wird in [Issue #74](https://github.com/praktimarc/kst4contest/issues/74) weiterverfolgt.
---
## v1.41.1 (2026-07-08)
**Hotfix für Texteingabe und Fokusverhalten**
### Behoben
- Das Nachrichteneingabefeld wurde nach einiger Zeit beziehungsweise bei bestimmten UI-Aktualisierungen unerwartet geleert.
- Beim Filtern oder Auswählen einer Station wurde der Eingabefokus unbeabsichtigt wieder in das Sendefeld verschoben.
Die korrigierte Version ist als [Release v1.41.1](https://github.com/praktimarc/kst4contest/releases/tag/v1.41.1) verfügbar.
---
## v1.41.0 (2026-07-01)
**Stationskarte, begrenzte Nachrichtenspeicher und bildschirmgerechtes Hauptfenster**
### Neu
- **Stationskarte:** Eine interaktive OpenStreetMap-Karte stellt aktive Chatmember mit brauchbarem Locator geografisch dar.
- **Antennensektor und Verbindungslinie:** Die Karte zeigt den aktuellen eigenen QTF, den konfigurierten Antennen-Öffnungswinkel, das maximale QRB und die Verbindung zur ausgewählten Station.
- **Maidenhead-Raster:** Ein an die Zoomstufe angepasstes Locator-Raster erleichtert die geografische Einordnung.
- **Geländeprofil:** Für ausgewählte Stationen kann ein Höhenprofil über die Open-Meteo Elevation API berechnet werden. Die aktive Datenquelle verwendet Copernicus GLO-90 und höchstens 100 gleichmäßig verteilte Abfragepunkte.
- **Geometrische Streckenanalyse:** Die Auswertung berücksichtigt Sichtlinie, Erdkrümmung mit `k = 4/3`, Radio- und Geländehorizont, erste Fresnel-Zone und eine grobe Hindernisabschätzung.
- **Lokaler Karten-Proxy:** Leaflet wird mit der Anwendung ausgeliefert. Kartenkacheln werden über einen lokalen Proxy geladen, damit keine externe JavaScript-Bibliothek zur Laufzeit nachgeladen werden muss. Für die OpenStreetMap-Kacheln und die Online-Höhendaten ist weiterhin eine Internetverbindung erforderlich.
### Geändert
- **Begrenzte Nachrichtenspeicher:** Die globale Chatnachrichtenliste wird oberhalb von 30.000 Einträgen auf 25.000 verkleinert. Der getrennte DX-Cluster-Speicher wird oberhalb von 10.000 Einträgen auf 8.000 verkleinert.
- **Bildschirmgerechte Startgröße:** Das Hauptfenster wird beim Start gegen den sichtbaren Bereich des primären Bildschirms geprüft und bei Bedarf verkleinert oder verschoben.
- **Kompaktere Benutzeroberfläche:** Mehrere Bereiche wurden für kleinere Bildschirme und verstellbare Divider angepasst.
### Einordnung der Kartenfunktion
Die Stationskarte und AirScout können dieselbe Gegenstation betreffen, führen aber getrennte Berechnungen durch. Aircraft-Scatter-Flugzeuge werden nicht in das Geländeprofil eingerechnet.
Im Quellcode vorhandene Klassen für Copernicus GLO-30, Offline-DEM-Import und weitere Terrain-Provider waren in v1.41 nicht Bestandteil der aktiv verwendeten Berechnungskette. Die tatsächlich verwendete Online-Höhenquelle ist Open-Meteo auf Basis von Copernicus GLO-90.
---
+269 -23
View File
@@ -614,48 +614,294 @@ Der Beacon ist für längeres CQ-Rufen auf einer festen Frequenz gedacht. Beim A
## Simplelogfile
Dateibasierte Log-Auswertung per Regex. Details: [Log-Synchronisation](Log-Synchronisation#methode-1-universal-file-based-callsign-interpreter-simplelogfile).
Details: [Log-Synchronisation](de-Log-Synchronisation#methode-1-universal-file-based-callsign-interpreter-simplelogfile).
---
## Cluster & QSO der anderen
## Globale Nachrichtenansichten
Ein separates Fenster zeigt den QSO-Fluss zwischen anderen Stationen. Besonders interessant in ruhigeren Nacht-Stunden während des Contests, wenn weniger Verkehr herrscht.
Das Stationsinfo-Panel und die PM-Tabelle beantworten Fragen zu einer bestimmten Station oder zur eigenen Kommunikation. Daneben gibt es Nachrichtenströme, die unabhängig von der aktuell ausgewählten Station betrachtet werden müssen.
Dieses Fenster kann minimiert werden, wenn es nicht benötigt wird. Zukünftig geplant: Filterung auf Stationen im ausgewählten QTF.
KST4Contest fasst diese globalen Informationen in drei Ansichten zusammen:
| Ansicht | Inhalt |
|---|---|
| **Public messages** | Öffentliche Chatnachrichten, CQ-Rufe und Beacons |
| **DXCluster messages** | Vom ON4KST-Server gelieferte DX-Cluster-Meldungen |
| **QSO of the other** | Gerichtete Chatnachrichten zwischen zwei anderen Stationen |
Die Ansichten befinden sich als Tabs im unteren Bereich des Hauptfensters. **Public messages** ist nach dem Programmstart vorausgewählt.
![Globale Nachrichtentabs im Hauptfenster](global_message_tabs.png)
### DXCluster messages
Der Tab **DXCluster messages** zeigt DX-Cluster-Meldungen, die über die bestehende ON4KST-Verbindung empfangen werden. Je nach Inhalt der Meldung stehen folgende Informationen zur Verfügung:
- Zeitpunkt,
- sendende beziehungsweise meldende Station,
- deren Locator,
- gemeldete Station,
- deren Locator,
- QRG,
- Meldungstext und
- globaler Worked-Status der gemeldeten Station.
Nicht jede vom Server übertragene Meldung enthält alle Felder. Ein leeres Locator- oder Nachrichtenfeld bedeutet deshalb nicht zwangsläufig einen Verarbeitungsfehler.
Diese Anzeige darf nicht mit dem [integrierten lokalen DX-Cluster-Server](de-DX-Cluster-Server) verwechselt werden. Der Tab zeigt empfangene ON4KST-Clusterinformationen. Der lokale Server erzeugt dagegen aus einer erkannten Richtungsgelegenheit einen Spot und gibt ihn an ein verbundenes Logprogramm weiter.
### QSO of the other
Der Tab **QSO of the other** zeigt gerichtete Chatnachrichten, bei denen weder Absender noch Empfänger die eigene Station sind. Öffentliche Nachrichten an `ALL` werden nicht aufgenommen.
Die Tabelle enthält:
| Spalte | Bedeutung |
|---|---|
| **Time** | Zeitpunkt der Chatnachricht |
| **Call TX** | Absender der Nachricht |
| **Last QRG TX** | zuletzt für den Absender bekannte QRG |
| **wkd TX?** | globaler Worked-Status des Absenders |
| **Call RX** | Empfänger der Nachricht |
| **Last QRG RX** | zuletzt für den Empfänger bekannte QRG |
| **wkd RX?** | globaler Worked-Status des Empfängers |
| **Message** | Inhalt der gerichteten Nachricht |
| **Category** | Chat-Kategorie der Nachricht |
Die beiden QRG-Spalten zeigen den zuletzt in KST4Contest bekannten Wert der jeweiligen Station. Das ist nicht zwangsläufig die Frequenz, auf der sich die beiden Stationen gerade verabreden. Die QRG kann aus einer früheren Nachricht stammen und sich inzwischen geändert haben.
Auch die Worked-Spalten sind bewusst bandunabhängig. Ein `X` bedeutet, dass das betreffende Basisrufzeichen auf mindestens einem Band gearbeitet wurde. Daraus folgt nicht, dass es auf der in der Tabelle sichtbaren oder vermuteten QRG bereits gearbeitet wurde.
Die Bezeichnung **QSO of the other** ist eine praktische Kurzform. Eine gerichtete Nachricht beweist weder, dass anschließend ein Funkkontakt zustande kam, noch dass beide Stationen tatsächlich auf derselben Frequenz arbeiten. Die Ansicht zeigt beobachtbare Koordination im Chat nicht das Logbuch der anderen Stationen.
### Zusätzliches Monitorfenster
Dieselben DX-Cluster-Meldungen und gerichteten Nachrichten stehen weiterhin im separaten Fenster **Cluster & QSO of the other** zur Verfügung. Dort erscheinen die DX-Cluster-Tabelle oben und die Nachrichten zwischen anderen Stationen darunter.
![Separates Cluster- und QSO-Monitorfenster](cluster_qso_monitor.png)
Das separate Fenster und die Tabs verwenden dieselben zugrunde liegenden Listen. Eine Meldung wird dadurch nicht doppelt empfangen oder doppelt gespeichert. Es handelt sich lediglich um zwei Darstellungen derselben Daten.
Das Monitorfenster kann über **Windows → Hide cluster / stranger QSOs** ausgeblendet und mit **Show cluster / stranger QSOs** wieder eingeblendet werden. Wer den Platz nicht benötigt, kann das Fenster daher schließen oder minimieren, ohne auf die entsprechenden Tabs im Hauptfenster verzichten zu müssen.
Die vollständigen Texte abgeschnittener Nachrichten erscheinen als Tooltip. Erkannte Webadressen können wie in den übrigen Nachrichtentabellen angeklickt und im Standardbrowser geöffnet werden.
Die Ansichten helfen dabei, Aktivität und Koordination anderer Stationen zu erkennen. Bei hohem Chat-Aufkommen entsteht daraus allerdings schnell mehr Information als Erkenntnis. Das separate Fenster ist deshalb vor allem dann nützlich, wenn ein bestimmter Kommunikationsfluss gezielt beobachtet werden soll.
---
## Stationskarte (ab v1.41)
## Stationskarte und Streckenanalyse (ab v1.41)
Eine interaktive OpenStreetMap-Karte zeigt die geografische Position aller aktiven Chatmember.
Eine lange Benutzerliste beantwortet zwei geografische Fragen nur unzureichend: Wo befinden sich die eingeloggten Stationen, und welche davon liegen ungefähr in der aktuellen Antennenrichtung? Die Stationskarte überträgt deshalb die bereits bekannten Locator-, Richtungs-, Band- und Worked-Informationen in eine interaktive Kartenansicht.
**Funktionen:**
Die Karte ist keine zweite, unabhängig verwaltete Stationsliste. Sie verwendet die aktuell durch die Filter der Benutzerliste sichtbaren Chatmember. Wird beispielsweise nach Entfernung, Richtung, Worked-Status oder einem bestimmten Band gefiltert, wirkt sich dies auch auf die dargestellten Stationen aus. In der Kopfzeile der Karte wird angezeigt, wie viele Stationen sichtbar sind und ob eine gefilterte Ansicht aktiv ist.
- Stationsmarker mit Rufzeichen-Labels, farblich nach Aktivität und Sked-Status
- **Antennen-Kegel** für die eigene Station
- **Verbindungslinie** zur aktuell ausgewählten Station
- **Maidenhead-Raster** (QRA-Locator-Gitter als Overlay)
- **Wegprofil-Diagramm**: Geländehöhen-Querschnitt zwischen eigener und ausgewählter Station, inklusive Fresnel-Zonen-Analyse und Horizonterkennung
- Mehrere Terrainquellen: **Copernicus GLO-30** (hochauflösendes DEM), **Open-Meteo API**, synthetischer Fallback und **Offline-DEM-Import** für den Betrieb ohne Internetverbindung
- Aircraft-Scatter-Weganalyse verknüpft mit den Geländedaten
![Stationskarte mit ausgewählter Station und eingeblendeter Streckenanalyse](station_map_path_analysis.png)
Die Karte funktioniert in gepackten Umgebungen (AppImage, Flatpak) ohne Zugriff auf externe CDNs: Die Kartenkacheln werden über einen lokalen Tile-Proxy abgerufen, die Leaflet.js-Bibliothek ist in der Anwendung eingebettet.
### Welche Stationen werden dargestellt?
Für einen Kartenmarker benötigt KST4Contest einen brauchbaren sechsstelligen Locator. Chatmember ohne einen solchen Locator können in der Benutzerliste vorhanden sein, erscheinen aber nicht auf der Karte.
Mehrere aktive Chat-Einträge desselben Basisrufzeichens werden für die Kartenansicht zusammengefasst. Das verhindert, dass beispielsweise getrennte Logins in mehreren Chat-Kategorien mehrere Marker an derselben geografischen Position erzeugen. Als sichtbares Rufzeichen und für die Detailinformationen wird die zuletzt geeignete aktive Variante verwendet.
Die Beschriftung eines Markers kann zusätzlich enthalten:
- die für die Station erkannten aktiven Bänder,
- `B+`, wenn mindestens ein eigenes aktiviertes und noch nicht gearbeitetes Band angeboten wird.
Die Bandangaben verwenden dieselbe Herleitung wie die Bandspalten, der Filter **New bands** und der Priority Score. Aktuelle QRG-Erkennungen, Bandangaben im Namensfeld, Worked-Informationen und manuelle NOT-QRV-Markierungen werden daher auch in der Kartenansicht konsistent berücksichtigt.
### Bedeutung der Markerfarben
| Darstellung | Bedeutung |
|---|---|
| Blauer Rand | Station ohne eine der nachfolgenden besonderen Markierungen |
| Gelber Rand | Das Basisrufzeichen wurde bereits auf mindestens einem Band gearbeitet |
| Grün | Für die Station besteht eine aus gerichteten Chatnachrichten hergeleitete Richtungsgelegenheit |
| Orange | Aktuell ausgewählte Station |
Treffen mehrere Zustände gleichzeitig zu, hat die für den Betrieb wichtigere Markierung Vorrang. Eine ausgewählte Station bleibt deshalb orange; eine Richtungsgelegenheit wird grün dargestellt, auch wenn das Rufzeichen bereits gearbeitet wurde.
Bei niedrigen Zoomstufen werden räumlich dicht beieinanderliegende Stationen zu einem Cluster zusammengefasst. Die Zahl im Cluster gibt die Anzahl der enthaltenen Stationen an. Ein Klick zoomt weiter hinein, wählt aber noch keine einzelne Station aus. Die aktuell ausgewählte Station und grün markierte Richtungsgelegenheiten bleiben auch bei niedriger Zoomstufe als einzelne Marker sichtbar.
### Auswahl und geografische Hilfen
Ein Klick auf einen einzelnen Stationsmarker:
1. wählt den dazugehörigen aktiven Chatmember aus,
2. scrollt die Benutzerliste zu diesem Eintrag,
3. aktualisiert den **Further Info**-Bereich und
4. bereitet das Rufzeichen wie bei einer Auswahl in der Benutzerliste als Nachrichtenziel vor.
Für die ausgewählte Station zeichnet KST4Contest eine Verbindungslinie von der eigenen Station zum Ziel. Der eingezeichnete Antennensektor verwendet:
- den aktuellen eigenen QTF,
- den konfigurierten Antennen-Öffnungswinkel und
- das konfigurierte Standard-Maximum-QRB.
Das Maidenhead-Raster passt seine Genauigkeit an die Zoomstufe und den sichtbaren Kartenausschnitt an. Es dient der räumlichen Orientierung; die Position eines Stationsmarkers wird aus dem sechsstelligen Locator abgeleitet und ist deshalb keine exakte GPS-Position.
### Strecken- und Geländeprofil
Nach Auswahl einer Station fordert KST4Contest ein Höhenprofil zwischen dem eigenen und dem fremden Locator an. Die aktive Online-Datenquelle ist die Open-Meteo Elevation API mit Geländedaten auf Basis von **Copernicus GLO-90**.
Die Online-Abfrage ist auf höchstens 100 gleichmäßig über die Strecke verteilte Höhenpunkte begrenzt. Eine 100 Kilometer lange Strecke wird damit grob im Abstand von etwa einem Kilometer abgetastet. Bei kürzeren Strecken wird der Abstand entsprechend kleiner, schmale Hindernisse können trotzdem zwischen zwei Abfragepunkten liegen.
Aus den Höhenpunkten berechnet KST4Contest unter anderem:
- das Geländeprofil,
- die geometrische Sichtlinie,
- die Erdkrümmung mit einem festen effektiven Erdradiusfaktor von `k = 4/3`,
- den geometrischen Radiohorizont beider Stationen,
- relevante Geländehorizonte,
- die erste Fresnel-Zone,
- die geringste Fresnel-Freiheit,
- den stärksten erkannten Eingriff in die Fresnel-Zone und
- eine grobe Einzelhindernis- beziehungsweise Knife-Edge-Abschätzung.
Die eingestellte eigene Antennenhöhe wird zur lokalen Geländehöhe addiert. Für die Gegenstation wird derzeit eine feste angenommene Antennenhöhe von 10 Metern über Grund verwendet.
Bewegst du die Maus über das Profil, wird der dazugehörige Abfragepunkt zusätzlich auf der Karte markiert. Dadurch lässt sich ein auffälliger Berg oder Geländeeinschnitt leichter einer geografischen Position zuordnen.
### Welche Frequenz wird für die Berechnung verwendet?
Die Frequenz beeinflusst insbesondere die Größe der Fresnel-Zone, die Freiraumdämpfung und das Link-Budget. KST4Contest versucht deshalb, für die ausgewählte Station eine passende Analysefrequenz zu bestimmen.
Vorrangig wird eine aktuell bekannte QRG auf einem eigenen aktivierten und für die Gegenstation nutzbaren Band verwendet. Fehlt eine geeignete QRG, wird aus den vorhandenen Bandinformationen ein automatisches Analyseband hergeleitet und dessen Standardfrequenz verwendet. Manuelle NOT-QRV-Markierungen werden dabei berücksichtigt.
Die tatsächlich verwendete Frequenz steht im Feld **Frequency** der Streckenanalyse. Sie sollte kontrolliert werden, wenn die automatische Zuordnung nicht zur vorgesehenen Funkverbindung passt. Eine Berechnung auf 144 MHz ist für eine geplante Verbindung auf 1296 MHz keine gleichwertige Näherung.
### Link-Budget und Tropo-Spalte
Zusätzlich zur geometrischen Bewertung erstellt KST4Contest eine vereinfachte Link-Budget-Abschätzung. Verwendet werden:
- die konfigurierte eigene Sendeleistung,
- der eigene Antennengewinn,
- die angenommene Sendeleistung der Gegenstation,
- der angenommene Antennengewinn der Gegenstation,
- eine frequenzabhängig geschätzte Speiseleitungsdämpfung,
- die Freiraumdämpfung und
- gegebenenfalls eine grobe zusätzliche Hindernisdämpfung.
Antennengewinne werden in `dBi` eingegeben. Ein in `dBd` bekannter Wert muss deshalb vor der Eingabe um `2,15 dB` erhöht werden.
Die Berechnung betrachtet beide Übertragungsrichtungen. Der daraus abgeleitete ungünstigere SSB-Wert wird als Tropo-Marge für die Station gespeichert und kann anschließend in der **Tropo**-Spalte, beim Sortieren und durch den Filter **Tropo >=0dB** verwendet werden.
Karte und Benutzerliste führen keine voneinander unabhängigen Berechnungen durch. Sie verwenden denselben Reachability-Service und denselben Ergebnisspeicher. Eine über die Karte oder mit **Calc selected** angestoßene Berechnung kann deshalb anschließend auch in der Benutzerliste erscheinen.
Es wird absichtlich keine automatische Online-Geländeabfrage für jeden sichtbaren Chatmember gestartet. Eine Berechnung erfolgt durch eine ausdrückliche Auswahl in der Karte oder über **Calc selected**. Das begrenzt API-Anfragen und verhindert, dass jede Tabellenaktualisierung eine neue Serie von Höhenabfragen auslöst.
### Pfadanalyse ausblenden
Das Geländeprofil und die ausführliche Analyse benötigen einen erheblichen Teil der Fensterhöhe. Werden sie gerade nicht gebraucht, können beide Bereiche gemeinsam mit **Hide path analysis** ausgeblendet werden. Die Karte nutzt den frei werdenden Platz unmittelbar.
![Stationskarte mit ausgeblendeter Pfadanalyse](station_map_compact.png)
Mit **Show path analysis** werden Profil und Detailwerte wieder eingeblendet. Das zuletzt berechnete Ergebnis bleibt erhalten. Die gewählte Sichtbarkeit wird in den Einstellungen gespeichert und beim nächsten Programmstart wiederhergestellt.
Der rechte Detailbereich ist über einen Divider in der Breite verstellbar. Er kann so weit verkleinert werden, dass mehr Platz für die Karte entsteht, ohne ein Rufzeichen mit üblicher Länge vollständig zu verdecken.
### Was sagt die Streckenanalyse nicht aus?
Die Auswertung ist ein geometrisches und rechnerisches Modell. Sie misst weder die tatsächliche Feldstärke noch die momentanen Ausbreitungsbedingungen.
Insbesondere kennt KST4Contest nicht:
- die wirkliche Antennenhöhe und den tatsächlichen Antennengewinn der Gegenstation,
- deren Sendeleistung und Speiseleitungsverluste,
- Gebäude, Bewuchs und andere Hindernisse, die im Höhenmodell nicht enthalten sind,
- lokale Störungen und Empfängereigenschaften,
- den aktuellen atmosphärischen K-Faktor,
- Inversionsschichten oder Ducting und
- die tatsächliche Antennenrichtung der Gegenstation.
Die unter **Mechanisms** genannten Ausbreitungswege sind eine allgemeine Einordnung anhand der Geländegeometrie. Eine Nennung von Aircraft Scatter bedeutet nicht, dass aktuelle Flugzeuge aus AirScout in die Geländeanalyse eingerechnet wurden.
Im Klartext: Ein freier Weg ist ein nützlicher positiver Hinweis. Ein geometrisch versperrter Weg bedeutet im VHF-, UHF- und Mikrowellenbereich aber nicht automatisch „unmöglich“. Ebenso garantiert ein positives Link-Budget kein QSO.
Bedienung: [Stationskarte in der Benutzeroberfläche](de-Benutzeroberflaeche#stationskarte)
Konfiguration: [Streckenanalyse und Link-Budget](de-Konfiguration#streckenanalyse-und-link-budget)
---
## Optimierte Nachrichtenverarbeitung / 30.000-Nachrichten-Limit (ab v1.41)
## Begrenzte Nachrichtenspeicher (ab v1.41)
Die internen Chat- und Nachrichtentabellen sind auf **30.000 Einträge** begrenzt. Ältere Nachrichten werden automatisch verworfen, sobald das Limit erreicht wird. Damit bleiben Speicherverbrauch und Darstellungsperformance auch bei mehrtägigen Contest-Betrieb stabil.
Während eines längeren Contests können mehrere zehntausend Chat- und DX-Cluster-Meldungen eintreffen. Würden diese Listen während der gesamten Programmlaufzeit unbegrenzt wachsen, stiege nicht nur der Speicherverbrauch. Auch das Filtern, Sortieren und Aktualisieren der darauf aufbauenden Tabellen würde zunehmend aufwendiger.
KST4Contest verwendet deshalb zwei getrennte, begrenzte Nachrichtenspeicher:
| Nachrichtenspeicher | Aufräumen ab | Größe nach dem Aufräumen |
|---|---:|---:|
| Chatnachrichten | mehr als 30.000 Einträge | 25.000 Einträge |
| DX-Cluster-Meldungen | mehr als 10.000 Einträge | 8.000 Einträge |
Neue Nachrichten werden am Anfang der jeweiligen Liste eingefügt. Wird der obere Grenzwert überschritten, entfernt KST4Contest die ältesten Einträge am Ende der Liste, bis die angegebene Zielgröße erreicht ist.
### Warum gibt es zwei Grenzwerte?
Der Speicher wird nicht nach jeder einzelnen Nachricht wieder exakt auf seine Maximalgröße verkleinert. Nach dem Aufräumen bleiben bei den Chatnachrichten 5.000 und bei den DX-Cluster-Meldungen 2.000 freie Plätze.
Dadurch muss KST4Contest nicht für jede anschließend eintreffende Nachricht erneut Listeneinträge entfernen. Das Aufräumen erfolgt blockweise und damit deutlich seltener.
### Welche Tabellen teilen sich einen Speicher?
Die folgenden Ansichten sind gefilterte Darstellungen derselben globalen Chatnachrichtenliste:
- **Public messages**,
- die PM-Tabelle,
- die Nachrichten im Bereich **Further Info** und
- **QSO of the other**.
Diese Tabellen speichern nicht jeweils zusätzlich bis zu 30.000 Nachrichten. Wird eine alte Chatnachricht aus dem gemeinsamen Speicher entfernt, verschwindet sie gleichzeitig aus allen darauf basierenden Ansichten.
Ebenso verwenden der Tab **DXCluster messages** und die DX-Cluster-Tabelle im separaten Monitorfenster denselben Cluster-Speicher. Das zusätzliche Fenster erzeugt weder eine zweite Nachrichtenverbindung noch eine Kopie der empfangenen Meldungen.
Chatnachrichten und DX-Cluster-Meldungen besitzen dagegen voneinander unabhängige Speicher und Grenzwerte. Ein hohes Aufkommen an öffentlichen Chatnachrichten verkleinert deshalb nicht den DX-Cluster-Speicher und umgekehrt.
### Keine dauerhafte Historie
Beide Nachrichtenspeicher liegen ausschließlich im Arbeitsspeicher. Sie werden weder in die interne Worked-Datenbank noch in eine andere lokale Nachrichtendatei geschrieben.
Nach einem Neustart beginnen die Tabellen wieder mit leeren Listen und werden ausschließlich aus den neu empfangenen Meldungen aufgebaut. Die Ansichten sind damit ein Arbeitsmittel für die laufende Sitzung und kein dauerhaftes Chatarchiv.
---
## Bildschirmgerechte Fenstergröße (ab v1.41)
## Bildschirmgerechte Größe des Hauptfensters (ab v1.41)
Beim Programmstart berechnet KST4Contest eine bildschirmgerechte Startgröße für das Hauptfenster:
KST4Contest speichert die zuletzt verwendete Größe des Hauptfensters. Das ist praktisch, solange das Programm beim nächsten Start auf einem vergleichbaren Bildschirm läuft. Wurde die Anwendung zuvor auf einem größeren Monitor verwendet, kann die gespeicherte Größe auf einem kleineren Bildschirm jedoch außerhalb des sichtbaren Bereichs liegen.
- Die gespeicherte Fenstergröße aus der letzten Session wird verwendet aber **niemals größer als der aktuelle Bildschirm**.
- Wenn KST4Contest zuletzt auf einem größeren Monitor betrieben wurde, wird das Fenster automatisch auf die aktuelle Anzeige verkleinert.
- Das UI-Layout ist **kompakter und reaktionsfähiger auf kleineren Bildschirmen**.
KST4Contest prüft die gespeicherte Größe deshalb beim Programmstart gegen den nutzbaren Bereich des primären Bildschirms.
Damit werden unbrauchbare, abgeschnittene Fenster beim Wechsel zwischen Geräten oder Monitoren verhindert.
### Wie wird die Startgröße bestimmt?
Sofern die gespeicherten Werte gültig sind, verwendet KST4Contest zunächst die zuletzt gespeicherte Höhe und Breite. Fehlen brauchbare Werte, gilt eine Standardgröße von:
- 1.234 Pixel Breite und
- 768 Pixel Höhe.
Als verfügbare Fläche verwendet KST4Contest nicht die vollständige Bildschirmauflösung, sondern den von JavaFX gemeldeten sichtbaren Bereich des primären Bildschirms. Taskleiste, Dock und vergleichbare Bereiche des Betriebssystems sind darin bereits ausgenommen.
Von dieser Fläche wird zusätzlich ein Sicherheitsabstand von 40 Pixeln abgezogen. Überschreitet die gespeicherte Breite oder Höhe den verbleibenden Platz, wird nur der betreffende Wert verkleinert.
Nachdem die Oberfläche mit dieser Scene-Größe aufgebaut wurde, prüft KST4Contest zusätzlich das tatsächliche native Fenster einschließlich seiner vom Betriebssystem erzeugten Rahmen und Titelleiste. Das Fenster wird bei Bedarf noch einmal verkleinert oder in den sichtbaren Bereich verschoben.
Damit werden zwei unterschiedliche Fälle abgefangen:
1. Die gespeicherte Inhaltsfläche ist größer als der aktuelle Bildschirm.
2. Die Inhaltsfläche passt, das vollständige native Fenster ragt durch Rahmen oder Position trotzdem über den sichtbaren Bereich hinaus.
### Was passiert mit dem Layout?
Die Oberfläche wird nicht als Ganzes proportional skaliert. Stattdessen erhält das Hauptfenster weniger Platz, und die dafür vorgesehenen UI-Bereiche reagieren auf die verfügbare Breite.
Die Filterleiste bleibt bei normaler Fensterbreite kompakt. Erst wenn der tatsächlich benötigte Platz nicht mehr ausreicht, werden Bedienelemente in zusätzliche Zeilen umgebrochen. Divider können weiterhin verwendet werden, um den Platz zwischen den Nachrichten- und Stationsbereichen aufzuteilen.
### Grenzen der automatischen Korrektur
Die Prüfung verwendet immer den **primären Bildschirm**. Sie stellt nicht die frühere Position auf einem bestimmten sekundären Monitor wieder her.
Die automatische Größenbegrenzung gilt derzeit außerdem nur für das Hauptfenster. Das Einstellungsfenster, das separate Cluster- und QSO-Monitorfenster sowie weitere Zusatzfenster verwenden weiterhin ihre jeweils gespeicherten Größen, ohne dieselbe zusätzliche Prüfung gegen den primären Bildschirm.
Im Klartext: Die Schutzfunktion verhindert vor allem, dass das zentrale Hauptfenster nach einem Wechsel auf einen kleineren Bildschirm unbenutzbar startet. Sie ist keine vollständige Verwaltung aller Fensterpositionen in einem wechselnden Mehrmonitor-Setup.
+20 -9
View File
@@ -50,15 +50,15 @@ Download, unterstützte Betriebssysteme und Installationswege sind im Kapitel [I
## Versionsstand dieses Handbuchs
Dieses Handbuch beschreibt die stabile Version **v1.41.1**.
Dieses Handbuch unterscheidet zwischen der veröffentlichten Stable-Version und dem aktuellen Entwicklungsstand.
Funktionen oder Änderungen, die nur im aktuellen Entwicklungsstand enthalten sind, werden ausdrücklich als **Nightly / v1.42** gekennzeichnet. Fehlt eine solche Kennzeichnung, bezieht sich die Beschreibung auf die stabile Version.
Die derzeit veröffentlichte Stable-Version ist **v1.41.1**. Funktionen oder Änderungen, die erst im Entwicklungsstand für v1.42 enthalten sind, werden ausdrücklich als **Nightly / v1.42** gekennzeichnet. Fehlt eine solche Kennzeichnung, bezieht sich die Beschreibung auf die Stable-Version.
- [Aktuelle stabile Version herunterladen](https://github.com/praktimarc/kst4contest/releases/latest)
- [Nightly-Builds und automatisierte Builds](https://github.com/praktimarc/kst4contest/actions)
- [Versionsgeschichte](de-Changelog)
- [Stable, Beta und Nightly herunterladen](https://kst4contest.hamradioonline.de/download/)
- [Veröffentlichte GitHub Releases](https://github.com/praktimarc/kst4contest/releases)
- [Versionsgeschichte und aktueller Nightly-Stand](de-Changelog)
Für einen Contest ist grundsätzlich die stabile Version zu empfehlen. Nightly-Builds enthalten neuere Korrekturen und Funktionen, können sich aber zwischen zwei Builds verändern. Sie sind sinnvoll, wenn eine bestimmte Änderung getestet werden soll weniger sinnvoll ist der erste Versuch zehn Minuten vor Contestbeginn.
Für einen Contest ist grundsätzlich die Stable-Version zu empfehlen. Nightly-Builds enthalten neuere Korrekturen und Funktionen, können sich aber zwischen zwei Builds verändern. Sie sind sinnvoll, wenn eine konkrete Änderung getestet werden soll. Der erste Versuch zehn Minuten vor Contestbeginn ist dagegen meistens eine recht effiziente Methode, gleichzeitig Software und Operator zu testen.
---
@@ -80,7 +80,7 @@ Für einen Contest ist grundsätzlich die stabile Version zu empfehlen. Nightly-
## Kontakt und Support
- **Download:** [Aktuelle stabile Version](https://github.com/praktimarc/kst4contest/releases/latest)
- **Download:** [Stable, Beta und Nightly](https://kst4contest.hamradioonline.de/download/)
- **Quellcode:** [praktimarc/kst4contest](https://github.com/praktimarc/kst4contest)
- **Fehler und Funktionswünsche:** [GitHub Issues](https://github.com/praktimarc/kst4contest/issues)
- **E-Mail:** praktimarc+kst4contest@gmail.com
@@ -112,6 +112,17 @@ In Datei- und Verzeichnisnamen wird teilweise noch der technische Name `praktiKS
## Danksagungen
KST4Contest wurde durch Rückmeldungen aus dem praktischen Contest-Betrieb wesentlich verbessert.
KST4Contest wurde durch Rückmeldungen aus dem praktischen Contest-Betrieb wesentlich verbessert. Viele Funktionen entstanden nicht aus einer theoretischen Anforderungsliste, sondern aus Situationen, in denen während eines Contests eine Information fehlte, zu spät sichtbar wurde oder schlicht an der falschen Stelle stand.
Besonderer Dank gilt Gianluca Costantino (IU3OAR), Alessandro Murador (IZ3VTH), Reczetár István (HA1FV), Viliam Petrik (OM0AAO, Idee zum DX-Cluster), Konrad Neitzel (DC9DJ, Projektstruktur), Andreas (DO5ALF, Webmaster von funkerportal.de), Franz van Velzen (PE0WGA, Tester), DN9APW als neuem Entwickler im Team und Master über die CI/CD pipelines sowie allen weiteren Testern und Ideengebern.
Besonderer Dank gilt:
- Gianluca Costantino (IU3OAR),
- Alessandro Murador (IZ3VTH),
- Reczetár István (HA1FV),
- Viliam Petrik (OM0AAO) für die Idee zum integrierten DX-Cluster,
- Konrad Neitzel (DC9DJ) für Unterstützung bei der Projektstruktur,
- Andreas (DO5ALF), Webmaster von funkerportal.de,
- Franz van Velzen (PE0WGA) für Tests sowie
- DN9APW (Philipp Wagner), der seit Mai 2025 an der Entwicklung und den CI/CD-Pipelines mitarbeitet.
Ebenso wichtig sind die Fehlermeldungen, Tests und konkreten Betriebserfahrungen aller weiteren Nutzer. Eine genaue Beschreibung eines reproduzierbaren Problems hilft dem Projekt meistens mehr als ein allgemeines „läuft gut“ auch wenn Letzteres natürlich angenehmer zu lesen ist.
+59
View File
@@ -62,6 +62,65 @@ Der Wert sollte zum eigenen Stationsaufbau und zum vorgesehenen Contestbetrieb p
---
### Streckenanalyse und Link-Budget
Die Streckenanalyse der Stationskarte verwendet einige Angaben aus der Stationskonfiguration. Diese Werte beschreiben das eigene Stationssetup und soweit keine individuellen Daten der Gegenstation vorliegen ein angenommenes Setup der Gegenstation.
Folgende Einstellungen werden berücksichtigt:
- **Own antenna height AGL [m]** gibt die Höhe der eigenen Antenne über dem lokalen Gelände an. Die Angabe bezieht sich auf *Above Ground Level* und nicht auf die Höhe über dem Meeresspiegel. KST4Contest addiert diesen Wert zur Geländehöhe am eigenen Standort.
- **Own TX power [W]** gibt die verwendete Sendeleistung der eigenen Station in Watt an.
- **Own ant. gain [dBi]** gibt den Antennengewinn der eigenen Station in dBi an.
- **DX OM TX power [W]** gibt die für die Gegenstation angenommene Sendeleistung in Watt an.
- **DX OM ant. gain [dBi]** gibt den für die Gegenstation angenommenen Antennengewinn in dBi an.
Für die Antennenhöhe der Gegenstation verwendet KST4Contest derzeit einen festen Wert von 10 m über dem lokalen Gelände. Die Leistungs- und Antennendaten der Gegenstation sind globale Annahmen. Sie ersetzen keine individuell bekannten Stationsdaten, ermöglichen aber eine einheitliche Abschätzung, wenn keine genaueren Informationen vorliegen.
Die Antennengewinne müssen in dBi angegeben werden. Falls ein Wert in dBd vorliegt, kann er näherungsweise wie folgt umgerechnet werden:
`dBi = dBd + 2.15`
Auch die aktuelle Antennenrichtung, die konfigurierte Strahlbreite, das maximale QRB und die für die eigene Station aktivierten Bänder beeinflussen die Darstellung oder Auswertung auf der Stationskarte. Die aktuelle QTF und die Strahlbreite bestimmen beispielsweise den eingezeichneten Antennensektor und die Hervorhebung von Stationen innerhalb dieses Bereichs.
Für die Berücksichtigung der Erdkrümmung verwendet die Streckenanalyse einen festen Faktor von `k = 4/3` für den effektiven Erdradius. Das ist eine übliche Näherung für eine durchschnittliche troposphärische Refraktion. Tatsächliche Ausbreitungsbedingungen können davon deutlich abweichen.
Das Link-Budget berücksichtigt unter anderem:
- die Entfernung zwischen beiden Stationen,
- die verwendete Frequenz,
- die konfigurierte Sendeleistung,
- die Antennengewinne,
- geschätzte Speiseleitungsverluste,
- den Freiraumverlust sowie
- eine grobe Zusatzdämpfung durch Hindernisse im Streckenprofil.
Die daraus berechnete Empfangsleistung und SSB- beziehungsweise CW-Marge sind technische Abschätzungen. Sie sollen dabei helfen, mögliche Verbindungen einzuordnen. Sie sind keine vollständige Feldstärkeprognose und können insbesondere aktuelle Wetterbedingungen, lokale Abschattungen, Mehrwegeausbreitung oder andere nicht bekannte Stationsparameter nicht vollständig berücksichtigen.
---
### Streckenanalyse und Link-Budget
Die Stationskarte verwendet mehrere Werte aus dem Reiter **Station**, um das Geländeprofil und das Link-Budget zur ausgewählten Gegenstation zu berechnen.
| Einstellung | Verwendung |
|---|---|
| **Own antenna height AGL** | Höhe der eigenen Antenne über dem lokalen Gelände in Metern |
| **Own TX power W** | Eigene Sendeleistung in Watt |
| **Own ant. gain dBi** | Gewinn der eigenen Antenne in dBi |
| **DX OM TX power W** | Angenommene Sendeleistung der Gegenstation in Watt |
| **DX OM ant. gain dBi** | Angenommener Antennengewinn der Gegenstation in dBi |
**AGL** bedeutet „above ground level“. Trage hier nicht die Höhe über dem Meeresspiegel ein. Die Geländehöhe am eigenen Standort stammt bereits aus dem abgerufenen Höhenprofil; die konfigurierte Antennenhöhe wird zu diesem Wert addiert.
Für die Antennenhöhe der Gegenstation verwendet KST4Contest derzeit einen festen Standardwert von 10 Metern über Grund. Eine stationsbezogene Antennenhöhe wird im ON4KST-Chat nicht übertragen.
Antennengewinne müssen in `dBi` eingetragen werden. Liegt ein Wert in `dBd` vor, gilt:
```text
dBi = dBd + 2,15 dB
## Server-Einstellungen (ab v1.31)
Der Chat-Server-DNS und -Port sind in den Preferences konfigurierbar:
+161 -13
View File
@@ -4,22 +4,170 @@
Version history of KST4Contest / PraktiKST.
---
For the latest changelog, please refer to GitHub. The previous changelog is below.
## v1.41
**Station Map, Performance, Responsive UI**
**New:**
- **Station Map**: Interactive OpenStreetMap-based map showing the geographic position of all active chat members. Includes station markers, antenna beam cone, connection line to the selected station, Maidenhead grid overlay, and a path profile chart with terrain elevation analysis (Fresnel zones, horizon detection). Terrain data from Copernicus GLO-30, Open-Meteo API, or offline DEM import. Aircraft scatter path analysis integrated. Works in AppImage and Flatpak without external CDN access (local tile proxy, bundled Leaflet.js).
**Changed:**
- **Message table limit raised to 30,000**: Chat and message tables are capped at 30,000 entries. Older messages are automatically discarded, keeping performance stable during multi-day contest operations.
- **Screen-aware window sizing**: On startup, the main window is sized to fit the current screen. If KST4Contest was last used on a larger monitor, the window is automatically scaled down. The UI layout is more compact and responsive on smaller screens.
Published Stable versions and their application packages are available under [GitHub Releases](https://github.com/praktimarc/kst4contest/releases). This page also lists changes from the current development version where they have already been implemented and tested.
---
## v1.42 Nightly / in development
> Status of this section: 10 August 2026.
> v1.42 is not a published Stable release yet. Further changes may be added before release.
v1.42 brings several previously separate calculations together. Band information, Worked status, NOT-QRV marks, callsign suffixes and frequencies are now used more consistently by the user list, station map, priority calculation and external interfaces.
### Added
- **Shared band-opportunity calculation:** A central `BandOpportunityResolver` evaluates recent QRGs, band designators in station names, active callsign variants, Worked information and NOT-QRV marks. The user list, **New bands**, band-upgrade hint, Priority Score, station map and automatic band selection now use the same basis.
- **Extended band status display:** The band columns now distinguish:
- `X` for worked on this band,
- `a` for an offered and unworked band of a completely new callsign,
- `B+` for an offered and unworked band of a callsign already worked elsewhere, and
- `o` for a locator square already worked on this band.
The codes can be combined, for example as `ao` or `B+o`. The additional `a` and `o` indicators can be hidden separately in the GUI settings.
- **50 and 70 MHz support:** Both bands are available in station settings, Worked and NOT-QRV handling, the user list, filters, the internal database, UCXLog processing and the Win-Test listener. Existing databases are extended with the required columns.
- **Global message tabs:** Public messages, ON4KST DX cluster messages and directed messages between other stations can be displayed directly in the main window. The existing separate monitor window remains available and uses the same underlying message stores.
- **Manual QTF input:** The current antenna direction can be changed directly in KST4Contest when PSTRotator is not being used.
- **Filter reset:** A dedicated reset button reliably removes the active user-list filter predicates.
- **Map clustering:** Stations close to each other are grouped at lower zoom levels. The selected station and relevant direction opportunities remain individually visible.
- **Hideable path analysis:** The terrain profile and analysis section of the station map can be hidden completely. The selected state is stored and restored at the next application start.
### Changed
- **More precise QRG recognition:** Complete and relative frequency references continue to be recognised. Bare three-digit numbers are treated as QRGs only when a frequency context is available. Signal reports, band designators and unrelated numbers therefore produce fewer false frequencies.
- **Station-specific frequency context:** For relative QRGs, KST4Contest first uses a band context for the same station which is no more than 30 minutes old. The globally configured fallback band is used only when this context is unavailable.
- **Fallback band dropdown:** The global fallback can only be selected from supported band values. It applies to the complete QRG parser, not merely to DX cluster spots.
- **Consistent QRG formatting:** Frequencies are displayed with at least three decimal places in the user list and message tables.
- **Band-aware AirScout and path calculations:** KST4Contest derives a realistic frequency for each station from its current QRG and known band information. AirScout receives canonical band values. The temporary 430 MHz fallback has been replaced with 432 MHz.
- **Shared propagation-frequency selection:** AirScout, **Calc selected** and the station-map path analysis use the same `PropagationFrequencyResolver`. A band selected explicitly in the Reachability dropdown is respected for manual calculations.
- **Separate callsign variants:** Active chat members are distinguished by their complete callsign, including suffix, and by chat category. `DN9APW`, `DN9APW-2` and similar logins therefore remain separate message targets.
- **Shared base-callsign information:** Worked flags, NOT-QRV information and Priority Scores continue to be evaluated across variants of the same base callsign. Separate message targets no longer result in contradictory Worked information.
- **Corrected Priority Score eligibility:** Stations without a common available band, or with an overriding NOT-QRV mark, are no longer offered as priority candidates. An open band at a station already worked elsewhere can receive a separate Priority Boost.
- **Extended sked creation:** The band is selected from those enabled locally. `SSB` or `CW` is selected explicitly for the Win-Test handover instead of attempting to infer the mode unreliably from the band.
- **More precise Win-Test sked handover:** The QRG must belong to the selected band. Visible KST suffixes are removed for the logging target while portable callsign components are preserved. `ADDSKED` timestamps are generated correctly. A failed handover does not remove the internal KST4Contest sked.
- **Exact sked targets:** The timeline and automatic reminders use the complete visible KST callsign. A sked for `DN9APW-2` is not accidentally sent to another variant of the same base callsign.
- **Reworked beacon and automatic replies:** Both chat categories use one shared timer while retaining separate enable switches and message texts. The minimum permitted interval is two minutes and message texts are limited to 120 characters. The stored beacon state is restored from the configuration at startup.
- **Central variable resolution:** Message variables used by beacons, shortcuts, snippets and other generated text are processed by one shared resolver.
- **Improved message tables:** Truncated messages show their complete text in a tooltip. Recognised web addresses can be opened in the system browser.
- **More compact filter bar:** Filters retain their compact arrangement at normal widths and wrap only when the available space is genuinely insufficient. This allows the centre divider to be moved further to the right.
- **DXLog full-log import:** In addition to `contactinfo`, the UCXLog-compatible UDP listener processes `contactreplace`. This allows a complete log broadcast by DXLog.net to be imported.
- **Improved version comparison:** Versions are compared semantically so that patch releases and Nightly versions are not misclassified by conversion to a floating-point number.
### Fixed
- **Long-running station-selection failure:** Chat members managed by the message thread have been decoupled from the JavaFX view. Simultaneous data and table updates therefore no longer cause broken selection models or concurrent-modification problems after longer runtimes.
- **No phantom chat members from UM3:** Historical or additional server messages no longer create user-list entries for stations which are not actually logged into the chat.
- **Messages to callsigns with suffixes:** Several active variants of the same base callsign no longer overwrite each other. This resolves [Issue #73](https://github.com/praktimarc/kst4contest/issues/73).
- **DX cluster locators:** The reporting and reported station no longer receive the same locator accidentally. This resolves [Issue #48](https://github.com/praktimarc/kst4contest/issues/48).
- **Worked state in “QSO of the other”:** The Worked columns again use the correct transmitting and receiving station.
- **Missing SECONDAP data:** A missing second aircraft-scatter opportunity no longer produces an invalid text selection and JavaFX exception when the field is edited.
- **Historical callsigns:** Highlighting or selecting a callsign which is no longer present in the active user list no longer causes an exception.
- **Win-Test sked time and callsign handling:** Timestamps, band-to-QRG assignment, KST suffixes and portable callsigns are handled correctly.
- **Filter reset:** All filter predicates are actually removed, and the visible button state again matches the effective filter state.
### Documentation and packaging
- The German and English manuals have been systematically checked against the source code, extended and supplied with current screenshots. The documentation now describes not only the controls, but also how information is derived and where the limits of a result lie.
- The AUR provides `kst4contest-bin`, `kst4contest` and `kst4contest-git` for Arch Linux.
- The download page distinguishes between Stable, Beta and Nightly and offers only packages which actually belong to the corresponding channel.
- Nightly packages are built automatically from the current `main` branch. Stable and Beta releases use predictable asset names for the supported platforms.
### Known limitations
- The active terrain provider uses Open-Meteo with Copernicus GLO-90 data and no more than 100 elevation samples per path.
- The atmospheric K factor is currently fixed at `4/3`.
- An antenna height of 10 metres above ground is assumed for the remote station.
- Aircraft-scatter information from AirScout and the terrain analysis in the station map remain separate assessments.
- More detailed configuration of station height, frequency and K factor is being tracked in [Issue #74](https://github.com/praktimarc/kst4contest/issues/74).
---
## v1.41.1 (2026-07-08)
**Hotfix for text input and focus handling**
### Fixed
- The message input field was unexpectedly cleared after some time or during particular UI updates.
- Filtering or selecting a station could move the input focus back to the send field unintentionally.
The corrected version is available as [Release v1.41.1](https://github.com/praktimarc/kst4contest/releases/tag/v1.41.1).
---
## v1.41.0 (2026-07-01)
**Station map, bounded message stores and screen-aware main window**
### Added
- **Station map:** An interactive OpenStreetMap-based map displays active chat members for which a usable locator is available.
- **Antenna sector and connection line:** The map shows the current local QTF, configured antenna beamwidth, maximum QRB and the path to the selected station.
- **Maidenhead grid:** A locator grid adapted to the current zoom level provides geographical orientation.
- **Terrain profile:** An elevation profile for a selected station can be requested from the Open-Meteo Elevation API. The active source uses Copernicus GLO-90 data and no more than 100 evenly distributed samples.
- **Geometrical path analysis:** The calculation includes line of sight, Earth curvature using `k = 4/3`, radio and terrain horizons, the first Fresnel zone and a rough obstruction estimate.
- **Local map proxy:** Leaflet is bundled with the application. Map tiles are loaded through a local proxy so that no external JavaScript library is required at runtime. An Internet connection is still required for OpenStreetMap tiles and online elevation data.
### Changed
- **Bounded message stores:** The global chat-message list is reduced from more than 30,000 entries to 25,000. The separate DX cluster store is reduced from more than 10,000 entries to 8,000.
- **Screen-aware startup size:** The main window is checked against the visible area of the primary screen at startup and reduced or repositioned when necessary.
- **More compact user interface:** Several UI sections were adapted for smaller displays and movable dividers.
### Scope of the map function
The station map and AirScout may refer to the same remote station, but their calculations remain separate. Aircraft used by AirScout are not included in the terrain profile.
Classes for Copernicus GLO-30, offline DEM imports and additional terrain providers existed in the source tree but were not part of the active calculation chain in v1.41. The elevation source actually used was Open-Meteo based on Copernicus GLO-90.
---
## v1.40 (2026-02-16)
**Major Feature Release: Score System, AP Timeline, Win-Test, PSTRotator**
+34
View File
@@ -48,6 +48,40 @@ Enter a realistic value for your antenna's beamwidth (in degrees). This value is
Maximum distance (in km) for which direction warnings should be triggered. A realistic value for DM5M is 900 km. Stations farther away are ignored for highlighting purposes.
### Path Analysis and Link Budget
The station map uses several values from the station settings for its path analysis. These values describe the local station setup and, where no individual information is available, an assumed setup for the remote station.
The following settings are used:
- **Own antenna height AGL [m]** specifies the height of the local antenna above the surrounding terrain. The value is *Above Ground Level*, not height above sea level. KST4Contest adds it to the terrain elevation at the local station.
- **Own TX power [W]** specifies the transmit power of the local station in watts.
- **Own ant. gain [dBi]** specifies the antenna gain of the local station in dBi.
- **DX OM TX power [W]** specifies the transmit power assumed for the remote station.
- **DX OM ant. gain [dBi]** specifies the antenna gain assumed for the remote station.
KST4Contest currently uses a fixed antenna height of 10 metres above the local terrain for the remote station. The remote power and antenna-gain values are global assumptions. They cannot replace individually known station data, but they provide a consistent basis when no better information is available.
Antenna gains must be entered in dBi. If a value is specified in dBd, it can be converted approximately as follows:
`dBi = dBd + 2.15`
The current antenna direction, configured beamwidth, maximum QRB and bands enabled for the local station also affect the map display or its assessment. The current QTF and beamwidth, for example, determine the displayed antenna sector and the highlighting of stations inside that sector.
The path analysis uses a fixed effective Earth-radius factor of `k = 4/3`. This is a common approximation for average tropospheric refraction. Actual propagation conditions can differ considerably.
The link budget takes into account:
- the distance between both stations,
- the analysis frequency,
- the configured transmit powers,
- the antenna gains,
- estimated feeder losses,
- free-space path loss, and
- a rough additional loss caused by obstructions in the terrain profile.
The resulting received power and SSB or CW margins are technical estimates. They help to classify a possible path, but they are not a complete field-strength prediction. Current weather conditions, local obstructions, multipath propagation and unknown station parameters cannot be represented completely.
---
## Server Settings (from v1.31)
+253 -24
View File
@@ -509,46 +509,275 @@ Automatic CQ messages in the public channel at a configurable interval. Recommen
## Simplelogfile
File-based log evaluation using regex. Details: [Log Synchronisation](Log-Sync#method-1-universal-file-based-callsign-interpreter-simplelogfile).
File-based log evaluation using regex. Details: [Log Synchronisation](en-Log-Sync#method-1-universal-file-based-callsign-interpreter-simplelogfile).
---
## Global Message Views
Most message tables in KST4Contest are deliberately tied either to the local station or to the station currently selected in the user list. Some message streams must, however, remain visible independently of that selection.
KST4Contest therefore provides three global message tabs below the main user list:
| Tab | Content |
|---|---|
| **Public messages** | Public chat messages, including CQ calls and beacon messages |
| **DXCluster messages** | DX cluster messages delivered by the ON4KST server |
| **QSO of the other** | Directed chat messages between chat logins other than the local station |
**Public messages** is selected by default. Changing the selected station does not affect any of these three views.
![Global message tabs below the main user list](global_message_tabs.png)
### DXCluster messages
The DX cluster table shows cluster messages received through the ON4KST connection. Depending on the information contained in the source message, the table displays:
- the time,
- the reporting station and its locator,
- the reported station and its locator,
- the QRG,
- the message text, and
- the global Worked state of the reported station.
An empty locator or another empty field does not necessarily indicate a processing error. The corresponding information may simply be absent from the source message.
This view must not be confused with the [built-in DX Cluster server](en-DX-Cluster-Server). The built-in server sends derived direction spots to connected logging software. The **DXCluster messages** tab displays cluster traffic received from ON4KST.
### QSO of the other
The **QSO of the other** table displays directed chat messages for which neither the sender nor the receiver is the local station. Messages addressed to `ALL` are not included.
The table contains the following columns:
| Column | Meaning |
|---|---|
| **Time** | Time of the chat message |
| **Call TX** | Complete callsign of the sender |
| **Last QRG TX** | Most recently detected QRG assigned to the sender |
| **wkd TX?** | Global Worked state of the sender |
| **Call RX** | Complete callsign of the receiver |
| **Last QRG RX** | Most recently detected QRG assigned to the receiver |
| **wkd RX?** | Global Worked state of the receiver |
| **Message** | Message text |
| **Category** | Chat category in which the message was received |
The QRG columns are not a historical record of the frequency used for the displayed message. They show the latest QRG currently known for the respective chat member. The value may originate from another message and may change when a newer QRG is detected.
The two Worked columns show the global callsign state. They do not indicate whether the station has already been worked on the QRG or band shown next to it.
The expression “QSO of the other” is used as a compact user-interface label. A directed chat message does not prove that an actual radio QSO has taken place. It may equally be a sked request, a frequency exchange or another private message between two chat logins.
### Separate monitor window
The DX cluster and QSO-of-the-other tables are additionally available in a separate monitor window. It places the DX cluster table above the directed messages between other stations.
![Separate monitor window for DX cluster traffic and directed messages between other stations](cluster_qso_monitor.png)
The tabs and the monitor window use the same underlying message stores. Opening the separate window does not create another connection, receive the messages a second time or maintain an independent history.
The window can be hidden or restored through:
**Windows → Hide cluster / stranger QSOs**
or:
**Windows → Show cluster / stranger QSOs**
The additional window is useful when these message streams should remain visible on a second monitor or while another part of the main window is being used. During periods with heavy chat traffic, the global tabs are usually more compact.
When a table cell cannot display its complete message, moving the mouse over the cell shows the full text in a tooltip. Web links beginning with `http://`, `https://` or `www.` can be opened in the system browser.
---
## Cluster & QSO of Others
## Station Map and Path Analysis (from v1.41)
A separate window showing the QSO flow between other stations. Particularly interesting during quieter night-time hours of a contest. This window can be minimised when not needed. Future plan: filtering to stations in your selected QTF.
The station map shows the geographical relationship between the local station and the chat members which are currently relevant in the main window. It is not a second, independent user list: filters applied to the chat-member table also determine which stations are passed to the map.
![Station map with path analysis](station_map_path_analysis.png)
### Stations and markers
A station can be displayed only if a usable six-character Maidenhead locator is available. Chat entries without a sufficiently precise locator remain in the user list but cannot be positioned reliably on the map.
Active chat variants belonging to the same normalised base callsign are combined into one map marker. This avoids several markers being placed at exactly the same position when, for example, a station is logged in with separate suffixes for different bands. The marker information includes the currently derived bands and, where applicable, open `B+` opportunities.
Marker colours provide a compact status indication:
| Colour | Meaning |
|---|---|
| Blue | Normal station marker |
| Yellow | The callsign has already been worked on at least one band |
| Green | The station is inside the current antenna sector and is relevant as a directional candidate |
| Orange | Currently selected station |
The selected state has the highest display priority, followed by the directional warning and Worked state. A selected station therefore remains orange even if it also meets one of the other conditions.
At lower zoom levels, nearby markers are combined into screen-based clusters. This is a display function and does not merge the underlying chat members. Selected stations and important directional candidates remain individually visible where possible.
Clicking a station marker selects the corresponding active chat member in the main window. KST4Contest scrolls to the entry in the user list, updates the **Further Info** panel and prepares the complete visible callsign as the message target. The chat suffix and category therefore remain relevant even though several variants may share one map marker.
### Antenna sector, connection line and locator grid
The map displays the local station together with the currently configured antenna direction, beamwidth and maximum QRB. These values form the visible antenna sector.
Selecting a remote station adds a connection line between both locations. The Maidenhead overlay provides a geographical reference without requiring the operator to translate every locator mentally.
The map does not know the actual radiation pattern, side lobes or elevation angle of the antenna. The displayed sector is therefore a geometrical representation of the configured horizontal beamwidth, not a complete antenna model.
### Terrain profile
For the selected path, KST4Contest requests terrain elevations from the Open-Meteo elevation service. The active provider uses Copernicus GLO-90 data and requests no more than 100 evenly distributed elevation coordinates for one path.
The terrain resolution and the sampling distance are not the same thing. On a long path, the distance between two requested points can be considerably larger than the nominal resolution of the elevation model. Small terrain features may therefore remain undetected.
The profile combines:
- terrain elevation,
- the geometrical line between both antennas,
- Earth-curvature correction using an effective Earth-radius factor of `k = 4/3`,
- the radio and terrain horizons,
- the first Fresnel zone,
- minimum Fresnel clearance,
- detected Fresnel-zone intrusion, and
- a rough knife-edge diffraction estimate for relevant obstructions.
The configured **Own antenna height AGL** is added to the terrain elevation at the local station. For the remote station, KST4Contest currently assumes an antenna height of 10 metres above the local terrain.
Moving the mouse over the path profile marks the corresponding position on the map. This makes it easier to identify which hill or terrain section causes a reported obstruction.
### Frequency selection
Fresnel clearance and link-budget results depend on frequency. KST4Contest therefore attempts to derive a usable analysis frequency from recent QRG or band information associated with the selected station.
The value displayed as **Frequency** in the analysis panel is the frequency actually used for the calculation. Check it before interpreting the result. A frequency which merely belongs to a possible band is still only an approximation if the station is expected to operate elsewhere.
This matters particularly on the microwave bands. The Fresnel zone becomes smaller as frequency increases, while free-space path loss and feeder loss increase. A calculation performed for the wrong band may therefore look plausible while describing a different radio path.
### Link budget and propagation assessment
The link-budget estimate uses:
- the configured local and remote transmit powers,
- the configured antenna gains,
- estimated feeder losses,
- free-space path loss, and
- a rough additional loss derived from the terrain obstruction.
Antenna gains must be entered in dBi. Values specified in dBd must first be converted.
The calculation produces an estimated received power and a bidirectional SSB margin. The result is also made available to the Reachability calculation used by the **Tropo** column and the corresponding filter in the main window.
The map and the table use the same `ReachabilityService` and calculation cache. A result calculated for the map can therefore also become available to the user list without repeating the complete request.
KST4Contest deliberately does not request an online terrain profile for every visible chat member whenever the list changes. That would create unnecessary API traffic and make normal chat processing dependent on a large number of external requests. Select the required station on the map or use **Calc selected** when a current calculation is needed.
### Compact view
The lower analysis panel can be hidden with **Hide path analysis** and restored with **Show path analysis**. Its visibility is stored in the preferences and restored at the next start.
The divider between the map and the analysis panel can be moved to allocate more space to either section. Hiding the analysis panel does not discard the selected station or close the map.
Operation of the map window is described under [Station Map](en-User-Interface#station-map).
Configuration of antenna height, power and gain is described under [Path Analysis and Link Budget](en-Configuration#path-analysis-and-link-budget).
### Limits of the result
The path analysis is an engineering estimate. Among other things, it does not know:
- the actual antenna height and station setup of the remote operator,
- vegetation, buildings and other clutter which is not represented in the elevation data,
- the current refractivity profile of the atmosphere,
- ducting, scattering or reflection conditions,
- local interference or receiver performance, or
- whether a detected QRG is still in use.
The **Mechanisms** indication lists propagation mechanisms which may be consistent with the calculated geometry. It does not prove that one of them is currently available.
Aircraft Scatter information is not currently coupled to the terrain-profile calculation. AirScout data and the path analysis may both describe the same remote station, but they remain separate assessments.
OpenStreetMap tiles and the active elevation provider require an Internet connection. Leaflet and the map application itself are bundled locally, and tile requests pass through a local proxy, but this proxy is not a permanent offline map store.
In plain terms: the analysis helps to identify plausible paths, obvious obstructions and incorrect assumptions. It does not replace propagation experience or a real signal.
---
## Bounded Message Stores (from v1.41)
During a long contest, KST4Contest may receive tens of thousands of chat and DX cluster messages. If these lists were allowed to grow without limit for the complete runtime, memory consumption would not be the only problem. Filtering, sorting and updating the tables built on top of them would also become increasingly expensive.
KST4Contest therefore uses two separate bounded message stores:
| Message store | Clean-up starts above | Size after clean-up |
|---|---:|---:|
| Chat messages | 30,000 entries | 25,000 entries |
| DX cluster messages | 10,000 entries | 8,000 entries |
New messages are inserted at the beginning of the respective list. When the upper limit is exceeded, KST4Contest removes the oldest entries from the end until the specified target size is reached.
### Why are there two thresholds?
The store is not reduced to its maximum size again after every single incoming message. After a clean-up, the chat-message store has room for another 5,000 entries and the DX cluster store for another 2,000.
KST4Contest therefore removes old entries in batches instead of modifying the end of the list again for every subsequent message. The clean-up runs much less frequently as a result.
### Which tables share a store?
The following views are filtered representations of the same global chat-message list:
- **Public messages**,
- the private-message table,
- the messages in the **Further Info** panel, and
- **QSO of the other**.
These tables do not each retain another 30,000 messages. When an old chat message is removed from the shared store, it disappears from all views based on that store at the same time.
The **DXCluster messages** tab and the DX cluster table in the separate monitor window likewise use the same cluster-message store. Opening the additional window neither creates a second message connection nor duplicates the received messages.
The chat and DX cluster stores are independent of each other. Heavy public-chat traffic therefore does not reduce the capacity available for DX cluster messages, and vice versa.
### No permanent history
Both message stores exist in memory only. They are written neither to the internal Worked database nor to another local message file.
After restarting KST4Contest, the tables begin with empty lists and are rebuilt exclusively from newly received messages. These views are working tools for the current session, not a permanent chat archive.
---
## Station Map (from v1.41)
## Screen-Aware Main Window Sizing (from v1.41)
An interactive OpenStreetMap-based map showing the geographic position of all active chat members.
KST4Contest stores the most recently used size of the main window. This is useful as long as the application is started on a comparable display the next time. If it was previously used on a larger monitor, however, the stored size may extend beyond the visible area of a smaller screen.
**Features:**
KST4Contest therefore checks the stored size against the usable area of the primary screen during startup.
- Station markers with callsign labels, coloured by activity and sked state
- Antenna **beam cone** visualisation for the own station
- **Connection line** to the currently selected station
- **Maidenhead grid** overlay (QRA locator grid)
- **Path profile chart**: Terrain elevation cross-section between own station and the selected station, including Fresnel zone analysis and obstruction/horizon detection
- Multiple terrain data sources: **Copernicus GLO-30** (high-resolution DEM), **Open-Meteo API**, synthetic fallback, and **offline DEM import** for air-gapped use
- Aircraft scatter path analysis integrated with the terrain data
### How is the startup size determined?
The map works in packaged environments (AppImage, Flatpak) without internet access to external CDNs: map tiles are fetched via a local tile proxy, and the Leaflet.js library is bundled inside the application.
If the stored values are valid, KST4Contest initially uses the last saved height and width. If no usable values are available, the following default size is used:
---
- 1,234 pixels wide and
- 768 pixels high.
## Optimised Message Handling / 30,000 Message Limit (from v1.41)
KST4Contest does not use the complete screen resolution as the available area. It uses the visual bounds reported by JavaFX for the primary screen. Taskbars, docks and similar operating-system areas are already excluded from these bounds.
The internal chat and message tables are capped at **30,000 entries**. Older messages are automatically discarded when the limit is reached. This keeps memory usage and rendering performance stable during multi-day contest operations.
An additional safety margin of 40 pixels is subtracted. If the stored width or height exceeds the remaining space, only the affected value is reduced.
---
After the user interface has been built with this content size, KST4Contest checks the complete native operating-system window, including its title bar and borders. The window is reduced or moved into the visible area again if necessary.
## Screen-Aware Window Sizing (from v1.41)
This catches two different cases:
On startup, KST4Contest calculates a screen-aware size for the main window:
1. The stored content area is larger than the current screen.
2. The content area fits, but the complete native window still extends beyond the visible area because of its borders or position.
- The stored window size from the previous session is used but **never larger than the current screen**.
- If KST4Contest was last used on a larger monitor, the window is automatically scaled down to fit the current display without clipping.
- The UI layout is more **compact and responsive on smaller screens**, showing the same information in less space.
### What happens to the layout?
This prevents unusable oversized windows when switching between machines or monitors.
The complete interface is not scaled proportionally. Instead, the main window receives less space and the UI areas designed for this situation react to the available width.
The filter bar remains compact at normal window sizes. Its controls wrap into additional rows only when their actual required width no longer fits. The dividers can still be used to distribute the available space between the message and station areas.
### Limits of the automatic correction
The check always uses the **primary screen**. It does not restore the previous position on a particular secondary monitor.
The automatic size restriction currently applies to the main window only. The settings window, the separate cluster and QSO monitor window and other auxiliary windows continue to use their stored sizes without the same additional check against the primary screen.
In plain terms: the protection mainly prevents the central main window from becoming unusable after moving to a smaller display. It is not a complete window-position manager for a changing multi-monitor setup.
+20 -8
View File
@@ -50,15 +50,15 @@ Downloads, supported operating systems and installation methods are described in
## Manual version
This manual describes the stable release **v1.41.1**.
This manual describes the current stable release of KST4Contest.
Features or changes that are only available in the current development version are explicitly marked as **Nightly / v1.42**. If no such label is present, the description refers to the stable release.
Functions that are only available in a Beta or Nightly build are marked accordingly. If no such note is present, the description applies to the stable release.
- [Download the current stable release](https://github.com/praktimarc/kst4contest/releases/latest)
- [Nightly and automated builds](https://github.com/praktimarc/kst4contest/actions)
- [Download Stable, Beta and Nightly builds](https://kst4contest.hamradioonline.de/download/)
- [GitHub releases](https://github.com/praktimarc/kst4contest/releases)
- [Version history](en-Changelog)
For contest operation, the stable release is generally the appropriate choice. Nightly builds contain newer fixes and features, but may change between builds. They are useful when a particular change needs testing. Trying one for the first time ten minutes before a contest is less useful.
The stable release is normally the appropriate choice for contest operation. Beta and Nightly builds contain newer fixes and functions, but may still change between builds. They are intended for testing specific changes. Ten minutes before a contest is usually not the ideal time for a first test.
---
@@ -80,7 +80,7 @@ For contest operation, the stable release is generally the appropriate choice. N
## Contact and support
- **Download:** [Current stable release](https://github.com/praktimarc/kst4contest/releases/latest)
- **Download:** [Stable, Beta and Nightly builds](https://kst4contest.hamradioonline.de/download/)
- **Source code:** [praktimarc/kst4contest](https://github.com/praktimarc/kst4contest)
- **Bug reports and feature requests:** [GitHub Issues](https://github.com/praktimarc/kst4contest/issues)
- **Email:** praktimarc+kst4contest@gmail.com
@@ -112,6 +112,18 @@ Some file and directory names still use the technical name `praktiKST`. They ref
## Acknowledgements
KST4Contest has benefited considerably from feedback gathered during actual contest operation.
Many functions and corrections in KST4Contest originate from observations made during actual contest operation. Reports that describe not only what happened, but also under which conditions it happened, are particularly useful.
Special thanks go to Gianluca Costantino (IU3OAR), Alessandro Murador (IZ3VTH), Reczetár István (HA1FV), Viliam Petrik (OM0AAO, DX Cluster idea), Konrad Neitzel (DC9DJ, project structure), Andreas (DO5ALF, webmaster of funkerportal.de), Franz van Velzen (PE0WGA, testing), and all other testers and contributors.
Special thanks go to:
- Gianluca Costantino (IU3OAR)
- Alessandro Murador (IZ3VTH)
- Reczetár István (HA1FV)
- Viliam Petrik (OM0AAO) for the DX Cluster idea
- Konrad Neitzel (DC9DJ) for his work on the project structure
- Andreas (DO5ALF), webmaster of funkerportal.de
- Franz van Velzen (PE0WGA) for testing
- Philipp (DN9APW) for further development of KST4Contest and the CI/CD infrastructure
- all other testers and contributors who supplied reproducible reports, ideas and corrections
Not every suggestion can be implemented unchanged. Nevertheless, reports from real operation remain an important basis for deciding which problems should be solved first.
+97 -6
View File
@@ -156,24 +156,115 @@ Calculation and limitations: [Priority Score and Priority List](en-Features#prio
---
## Cluster & QSO of Others
## Station Map
Separate window (can be minimised). Shows the communication flow between other stations interesting during quieter contest periods.
The station map is opened or closed through:
**Windows → Show / hide station map**
The window uses the chat members currently visible in the filtered user list. Changing the QRB, QTF, Worked, band or Reachability filters can therefore also change the stations shown on the map.
A station can additionally be opened directly from the **Further Info** panel using **Show on map**. This selects the station on the map and requests the associated path analysis.
Stations with the same normalised base callsign and position are combined into one marker. At lower zoom levels, nearby markers may additionally be displayed as clusters. These are display groups only; the individual chat logins remain separate message targets inside KST4Contest.
Clicking a station marker:
1. selects the corresponding chat member,
2. scrolls the main user list to that entry,
3. updates the **Further Info** panel, and
4. prepares the complete visible callsign as the message target.
The map details for the selected station include its locator, QRB, QTF, detected bands and available band opportunities. **Trigger cluster spot** sends a spot through the built-in local DX Cluster server so that connected logging software can receive the selected station and QRG.
The path-analysis section shows the terrain profile and the calculated route between both stations. Depending on the available data, it includes:
- the analysis frequency,
- line-of-sight and horizon information,
- Fresnel-zone clearance,
- detected obstructions,
- an estimated link budget,
- received power and SSB margin, and
- a short assessment of the path.
Moving the mouse over the terrain profile highlights the corresponding geographical position on the map.
The analysis can be hidden using **Hide path analysis** when more space is required for the map. The compact state displays **Path analysis is hidden.** together with the **Show path analysis** button.
![Station map with hidden path analysis](station_map_compact.png)
The selected station and map contents remain available while the analysis panel is hidden. The setting is stored and restored at the next start.
Calculation method and limitations: [Station Map and Path Analysis](en-Features#station-map-and-path-analysis-from-v141).
---
## Global Message Tabs and Monitor Window
Three global message tabs are located below the main user list. Unlike the **Further Info** panel, their contents do not depend on the station currently selected.
| Tab | Displayed messages |
|---|---|
| **Public messages** | All public chat messages, including CQ calls and beacons |
| **DXCluster messages** | DX cluster messages received from the ON4KST server |
| **QSO of the other** | Directed messages between chat logins other than the local station |
The **Public messages** tab is selected by default.
![Global message tabs below the main user list](global_message_tabs.png)
The **DXCluster messages** table contains the time, reporting and reported stations, locators, QRG, message text and global Worked state where these values are available in the received message.
The **QSO of the other** table contains:
- the complete sender and receiver callsigns,
- the latest QRG currently known for each station,
- the global Worked state of each station,
- the message text, and
- the chat category.
The displayed QRG is not necessarily the frequency on which the stations intend to make a contact. It is the latest QRG currently associated with the respective chat member. The Worked state is global and not specific to the displayed QRG or band.
A directed chat message in this table does not prove that a radio QSO has taken place. The table also contains sked requests, frequency exchanges and other directed messages between third-party chat logins.
### Separate monitor window
The DX cluster and QSO-of-the-other tables can also be displayed together in a separate window.
![Separate monitor window for DX cluster traffic and directed messages between other stations](cluster_qso_monitor.png)
The separate window and the tabs use the same underlying messages. Hiding the window does not stop message processing or remove messages from the tabs.
Use **Windows → Hide cluster / stranger QSOs** to hide the window and **Windows → Show cluster / stranger QSOs** to restore it.
If a message is too long for its table cell, moving the mouse over the cell displays the complete text in a tooltip. Links beginning with `http://`, `https://` or `www.` can be opened in the system browser.
---
## Menu
### Window
- **Use Dark Mode** (from v1.26): Toggle dark colour scheme on/off.
### Windows
- **Hide cluster / stranger QSOs** hides the separate monitor window for DX cluster messages and directed messages between other stations.
- **Show cluster / stranger QSOs** restores the monitor window.
- **hide options** hides the settings window.
- **show options** restores the settings window.
- **Use dark mode design** activates the dark colour scheme.
- **Use default mode design** restores the default colour scheme.
- **Show / hide station map** opens or closes the separate station-map and path-analysis window.
---
## Window Sizes and Dividers
From **v1.21**, clicking **"Save Settings"** also saves window sizes and divider positions of all panels in the configuration file, which are restored on the next start.
When **Save Settings** is clicked, KST4Contest stores the programme-window sizes and the positions of the relevant dividers in the configuration file. These values are reused at the next start.
The main window is additionally checked against the visible area of the primary screen during startup. If the stored size is too large, KST4Contest reduces and moves the window so that it remains accessible. The complete process is described under [Screen-Aware Main Window Sizing](en-Features#screen-aware-main-window-sizing-from-v141).
The other programme windows do not currently use this additional size restriction. If, for example, the separate monitor window appears too large after moving to a smaller screen, its size must be corrected manually and stored again using **Save Settings**.
If the layout has become inconvenient, first move the dividers back to usable positions and save the settings again. Deleting the configuration file also resets the UI values, but it removes the other stored programme settings as well. It should therefore be used only when the interface cannot be restored in another way.
If you encounter display problems: delete the configuration file → KST4Contest creates new default values.
---
Binary file not shown.

After

Width:  |  Height:  |  Size: 78 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 233 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.4 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.5 MiB

+1013
View File
File diff suppressed because it is too large Load Diff
Binary file not shown.
Binary file not shown.

After

Width:  |  Height:  |  Size: 264 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.9 KiB

@@ -5,13 +5,19 @@ import java.net.DatagramPacket;
import java.net.DatagramSocket;
import java.net.InetAddress;
import java.nio.charset.StandardCharsets;
import java.util.ArrayList;
import java.util.LinkedHashSet;
import java.util.List;
import java.util.Locale;
import java.util.Set;
import java.util.TimerTask;
import java.util.logging.Level;
import java.util.logging.Logger;
import kst4contest.model.Band;
import kst4contest.model.ChatMember;
/**
* Sends periodical path requests and an AirScout watchlist for the currently
* active ON4KST stations.
@@ -24,8 +30,17 @@ public class AirScoutPeriodicalAPReflectionInquirerTask extends TimerTask {
private static final String BROADCAST_ADDRESS = "255.255.255.255";
private final ChatController client;
/*
* ASWATCHLIST is sent as one common list. Remember one syntactically valid
* AirScout band value so an empty list can still be sent on a later cycle
* to remove stations which are no longer active.
*/
private String lastWatchListBandValue;
public AirScoutPeriodicalAPReflectionInquirerTask(
ChatController client
) {
@@ -50,9 +65,6 @@ public class AirScoutPeriodicalAPReflectionInquirerTask extends TimerTask {
client.getChatPreferences().getAirScout_asClientNameString();
String serverIdentifier =
client.getChatPreferences().getAirScout_asServerNameString();
String bandValue =
client.getChatPreferences().getAirScout_asBandString();
String ownCallSign = normalizeOwnCallSign(
client.getChatPreferences().getStn_loginCallSign()
);
@@ -79,14 +91,10 @@ public class AirScoutPeriodicalAPReflectionInquirerTask extends TimerTask {
+ "\" \"" + serverIdentifier + "\" ";
String ownStation = ownCallSign + "," + ownLocator;
StringBuilder watchListMessage = new StringBuilder(
watchListPrefix
+ bandValue
+ ","
+ ownStation
);
List<ChatMember> activeMembers = client.snapshotChatMembers();
List<String> watchListTargets = new ArrayList<>();
Set<String> processedCallsigns = new LinkedHashSet<>();
String watchListBandValue = null;
int port = client.getChatPreferences()
.getAirScout_asCommunicationPort();
@@ -102,11 +110,38 @@ public class AirScoutPeriodicalAPReflectionInquirerTask extends TimerTask {
continue;
}
if (member.getQrb()
if (member.getQrb() == null
|| member.getQrb()
>= client.getChatPreferences().getStn_maxQRBDefault()) {
continue;
}
String callsignKey = member.getCallSignRaw();
if (callsignKey == null || callsignKey.isBlank()) {
callsignKey = member.getCallSign();
}
if (callsignKey == null
|| !processedCallsigns.add(
callsignKey.trim().toUpperCase(Locale.ROOT)
)) {
continue;
}
/*
* The resolver may deliberately return an exact QRG. AirScout must
* only see a canonical protocol band value such as 4320000.
*/
String bandValue = canonicalizeAirScoutBandValue(
client.resolveAirScoutBandValue(member)
);
if (bandValue == null) {
continue;
}
if (watchListBandValue == null) {
watchListBandValue = bandValue;
}
String targetStation =
member.getCallSign() + "," + member.getQra();
@@ -126,19 +161,47 @@ public class AirScoutPeriodicalAPReflectionInquirerTask extends TimerTask {
pathQuery
);
watchListMessage
.append(",")
.append(targetStation);
watchListTargets.add(targetStation);
}
watchListMessage.append(" ");
/*
* AirScout keeps one watchlist per client/server pair. Do not send
* separate lists for the individual station bands because a later
* list would replace stations from an earlier one.
*
* If there are no targets in this cycle, reuse the last valid band
* token and send an empty list so AirScout can clear stale entries.
*/
if (watchListBandValue == null) {
watchListBandValue = lastWatchListBandValue;
}
if (watchListBandValue != null) {
StringBuilder watchListMessage = new StringBuilder(
watchListPrefix
+ watchListBandValue
+ ","
+ ownStation
);
for (String targetStation : watchListTargets) {
watchListMessage
.append(",")
.append(targetStation);
}
watchListMessage.append(" ");
sendPacket(
socket,
broadcastAddress,
port,
watchListMessage.toString()
);
lastWatchListBandValue = watchListBandValue;
}
sendPacket(
socket,
broadcastAddress,
port,
watchListMessage.toString()
);
} catch (IOException exception) {
LOGGER.log(
Level.WARNING,
@@ -148,6 +211,60 @@ public class AirScoutPeriodicalAPReflectionInquirerTask extends TimerTask {
}
}
/**
* Converts a frequency-like value returned by the station resolver into the
* canonical band token expected by the AirScout UDP protocol.
*
* <p>The internal resolver may keep an exact working frequency for path
* analysis. This method removes that precision only at the AirScout protocol
* boundary. For example, {@code 4321740} is sent to AirScout as
* {@code 4320000}.</p>
*
* @param resolvedValue frequency-like AirScout value produced by the resolver
* @return canonical AirScout band value, or {@code null} if unsupported
*/
private String canonicalizeAirScoutBandValue(String resolvedValue) {
if (resolvedValue == null || resolvedValue.isBlank()) {
return null;
}
String normalizedValue = resolvedValue.trim();
if ("off".equalsIgnoreCase(normalizedValue)
|| "auto".equalsIgnoreCase(normalizedValue)) {
return null;
}
final long numericValue;
try {
numericValue = Long.parseLong(normalizedValue);
} catch (NumberFormatException exception) {
LOGGER.log(
Level.WARNING,
"Unsupported AirScout band value: " + resolvedValue,
exception
);
return null;
}
double frequencyMHz = numericValue / 10_000.0;
Band band = Band.fromFrequency(frequencyMHz);
if (band == null) {
LOGGER.warning(
"AirScout query skipped because frequency "
+ frequencyMHz
+ " MHz does not belong to a supported band."
);
return null;
}
return band.getPrefix() + "0000";
}
/**
* Removes the ON4KST login suffix because AirScout expects the actual
* station callsign, for example 9A1W instead of 9A1W-2.
@@ -34,7 +34,7 @@ import java.util.concurrent.TimeUnit;
import java.util.function.Consumer;
import java.util.function.Predicate;
import java.nio.charset.StandardCharsets;
import kst4contest.logic.FrequencyTextParser;
@@ -450,8 +450,15 @@ public class ChatController implements ThreadStatusCallback, PstRotatorEventList
chatPreferences.getAirScout_asClientNameString();
String serverIdentifier =
chatPreferences.getAirScout_asServerNameString();
String bandValue =
chatPreferences.getAirScout_asBandString();
String bandValue = resolveAirScoutBandValue(remoteChatMember);
if (bandValue == null) {
System.out.println(
"[AirScout, info]: Show-path request ignored because no "
+ "usable propagation frequency could be resolved."
);
return;
}
int port =
chatPreferences.getAirScout_asCommunicationPort();
@@ -498,6 +505,30 @@ public class ChatController implements ThreadStatusCallback, PstRotatorEventList
}
}
/**
* Resolves the AirScout protocol frequency for one station. In automatic mode
* this uses the same station-specific resolution as the internal path analysis;
* manual mode keeps the configured forced value for compatibility.
*
* @param remoteChatMember target station
* @return AirScout frequency in 100-Hz units, or {@code null} if auto mode has
* no safe result
*/
public String resolveAirScoutBandValue(ChatMember remoteChatMember) {
if (!chatPreferences.isAirScout_autoBandSelectionEnabled()) {
return chatPreferences.getAirScout_asBandString();
}
if (reachabilityService == null) {
return null;
}
var resolution = reachabilityService
.resolveAutomaticPropagationFrequency(remoteChatMember);
return resolution == null ? null : resolution.getAirScoutBandValue();
}
/**
* starts the calculation scheduler for scores / priorities of skeds to be made
*/
@@ -1459,6 +1490,38 @@ private ObservableList<String>
);
}
/**
* Uses one unambiguous explicit QRG from the current station name as the
* initial compatibility frequency.
*
* <p>Multiple explicit QRGs are valid band evidence, but there is no safe
* assumption which one is the current run frequency. Therefore the legacy
* frequency property is initialized only when exactly one explicit QRG exists.</p>
*/
private void initializeFrequencyFromStationNameIfUnambiguous(
ChatMember member
) {
if (member == null) {
return;
}
List<FrequencyTextParser.DetectedFrequency> detectedFrequencies =
FrequencyTextParser.findExplicitFrequencies(
member.getName()
);
if (detectedFrequencies.size() != 1) {
return;
}
member.initializeFrequencyIfEmpty(
detectedFrequencies
.get(0)
.getFrequencyMHz()
);
}
/**
* Adds or replaces an active chat member in the worker-thread model and mirrors
* that change to the JavaFX list. This is the only supported path for ON4KST
@@ -1470,6 +1533,8 @@ private ObservableList<String>
return;
}
initializeFrequencyFromStationNameIfUnambiguous(member);
activeChatMembersByCallAndCategory.put(key, member);
runOnFxThread(() -> {
@@ -1652,6 +1717,9 @@ private ObservableList<String>
}
activeMember.setName(updatedMember.getName());
initializeFrequencyFromStationNameIfUnambiguous(
activeMember
);
activeMember.setQra(updatedMember.getQra());
activeMember.setState(updatedMember.getState());
activeMember.setLastActivity(updatedMember.getLastActivity());
@@ -18,6 +18,7 @@ import kst4contest.ApplicationConstants;
import kst4contest.locatorUtils.DirectionUtils;
import kst4contest.locatorUtils.Location;
import kst4contest.model.*;
import kst4contest.logic.FrequencyTextParser;
/**
*
@@ -58,7 +59,7 @@ public class MessageBusManagementThread extends Thread {
* would be converted into plausible but incorrect frequencies.
*/
private static final Pattern SMART_FREQUENCY_PATTERN = Pattern.compile(
"(?<![\\d])(\\d{3,5}[.,]\\d{1,3}(?:[.,]\\d{1,3})?)(?![\\d])"
"(?<![\\d])(\\d{2,5}[.,]\\d{1,3}(?:[.,]\\d{1,3})?)(?![\\d])"
+ "|(?<![\\d])([.,]\\d{3}(?:[.,]\\d{1,3})?)(?![\\d])"
+ "|(?<=\\s|^)(\\d{3})(?=\\s|$)"
);
@@ -319,16 +320,28 @@ public class MessageBusManagementThread extends Thread {
try {
String reconstructed =
candidateBand.getPrefix() + "." + foundRaw;
double candidateFrequency = Double.parseDouble(
normalizeFrequencyString(reconstructed)
);
candidateBand.getPrefix()
+ "."
+ foundRaw;
if (candidateBand.isPlausible(candidateFrequency)
FrequencyTextParser.DetectedFrequency detectedFrequency =
FrequencyTextParser.parseExplicitFrequency(
reconstructed
);
if (detectedFrequency != null
&& detectedFrequency.getBand() == candidateBand
&& info.timestampEpoch > bestTimestamp) {
finalDetectedFrequency = candidateFrequency;
finalDetectedBand = candidateBand;
bestTimestamp = info.timestampEpoch;
finalDetectedFrequency =
detectedFrequency.getFrequencyMHz();
finalDetectedBand =
candidateBand;
bestTimestamp =
info.timestampEpoch;
}
} catch (NumberFormatException ignored) {
// Try the next known band.
@@ -357,27 +370,40 @@ public class MessageBusManagementThread extends Thread {
try {
String reconstructed =
fallbackBand.getPrefix() + "." + foundRaw;
double candidateFrequency = Double.parseDouble(
normalizeFrequencyString(reconstructed)
);
fallbackBand.getPrefix()
+ "."
+ foundRaw;
if (fallbackBand.isPlausible(candidateFrequency)) {
finalDetectedFrequency = candidateFrequency;
finalDetectedBand = fallbackBand;
FrequencyTextParser.DetectedFrequency detectedFrequency =
FrequencyTextParser.parseExplicitFrequency(
reconstructed
);
if (detectedFrequency != null
&& detectedFrequency.getBand() == fallbackBand) {
finalDetectedFrequency =
detectedFrequency.getFrequencyMHz();
finalDetectedBand =
fallbackBand;
}
} catch (NumberFormatException ignored) {
// The matched value cannot be converted into a frequency.
}
}
} else {
try {
finalDetectedFrequency = Double.parseDouble(
normalizeFrequencyString(foundRaw)
);
finalDetectedBand = Band.fromFrequency(finalDetectedFrequency);
} catch (NumberFormatException ignored) {
// Continue with the next possible match in the message.
FrequencyTextParser.DetectedFrequency detectedFrequency =
FrequencyTextParser.parseExplicitFrequency(
foundRaw
);
if (detectedFrequency != null) {
finalDetectedFrequency =
detectedFrequency.getFrequencyMHz();
finalDetectedBand =
detectedFrequency.getBand();
}
}
@@ -462,22 +488,22 @@ public class MessageBusManagementThread extends Thread {
* Example: "144.210.10" -> "144.21010"
* Example: "144.210" -> "144.210"
*/
private String normalizeFrequencyString(String rawInput) {
// Input is already guaranteed to have only dots as separators (commas replaced earlier)
int firstDotIndex = rawInput.indexOf(".");
if (firstDotIndex != -1) {
// Check if there are more dots after the first one
String decimalPart = rawInput.substring(firstDotIndex + 1);
if (decimalPart.contains(".")) {
// Remove all subsequent dots to make it a valid double
decimalPart = decimalPart.replace(".", "");
return rawInput.substring(0, firstDotIndex) + "." + decimalPart;
}
}
return rawInput;
}
// private String normalizeFrequencyString(String rawInput) {
// // Input is already guaranteed to have only dots as separators (commas replaced earlier)
//
// int firstDotIndex = rawInput.indexOf(".");
//
// if (firstDotIndex != -1) {
// // Check if there are more dots after the first one
// String decimalPart = rawInput.substring(firstDotIndex + 1);
// if (decimalPart.contains(".")) {
// // Remove all subsequent dots to make it a valid double
// decimalPart = decimalPart.replace(".", "");
// return rawInput.substring(0, firstDotIndex) + "." + decimalPart;
// }
// }
// return rawInput;
// }
/**
@@ -1167,27 +1193,31 @@ public class MessageBusManagementThread extends Thread {
if (client.getChatPreferences().isNotify_dxClusterServerEnabled()) {
try {
if (newMessageArrived.getSender().getFrequency() != null) {
//TODO: testing for next version 3.33: additional information will be displayed in cluster if there is such information
ChatMember sender = newMessageArrived.getSender();
String detectedFrequency = sender.getFrequency() == null
? null
: sender.getFrequency().getValue();
if (detectedFrequency != null && !detectedFrequency.isBlank()) {
/*
* The DX Cluster spot must not depend on AirScout data. A known
* frequency and a valid directional opportunity are sufficient.
* Available AP information is added only as an optional comment.
*/
ChatMember onlyForSpottingObject = new ChatMember();
onlyForSpottingObject.setCallSign(newMessageArrived.getSender().getCallSign());
onlyForSpottingObject.setFrequency(newMessageArrived.getSender().getFrequency());
onlyForSpottingObject.setCallSign(sender.getCallSign());
onlyForSpottingObject.setFrequency(sender.getFrequency());
onlyForSpottingObject.setQra(
buildDxClusterSpotComment(sender)
);
if (newMessageArrived.getSender().getAirPlaneReflectInfo().getAirPlanesReachableCntr() > 0) {
onlyForSpottingObject.setQra(newMessageArrived.getSender().getQra() + " , AP: " +
newMessageArrived.getSender().getAirPlaneReflectInfo().getRisingAirplanes().get(0).getArrivingDurationMinutes() + "min, " +
newMessageArrived.getSender().getAirPlaneReflectInfo().getRisingAirplanes().get(0).getPotential() + "%");
this.client
.getDxClusterServer()
.broadcastSingleDXClusterEntryToLoggers(
onlyForSpottingObject
);
if (newMessageArrived.getSender().getAirPlaneReflectInfo().getAirPlanesReachableCntr() > 1) {
onlyForSpottingObject.setQra(newMessageArrived.getSender().getQra() + "; " +
newMessageArrived.getSender().getAirPlaneReflectInfo().getRisingAirplanes().get(1).getArrivingDurationMinutes() + "min, " +
newMessageArrived.getSender().getAirPlaneReflectInfo().getRisingAirplanes().get(1).getPotential() + "%");
}
} else {
onlyForSpottingObject.setQra(newMessageArrived.getSender().getQra());
}
this.client.getDxClusterServer().broadcastSingleDXClusterEntryToLoggers(onlyForSpottingObject);
}
} catch (Exception exception) {
System.out.println("[MSGBUSMGT, ERROR:] DXCluster messageserver error while processing spot for 0: " + newMessageArrived.getSender().getCallSign() + " // " + exception.getMessage());
@@ -1694,6 +1724,70 @@ public class MessageBusManagementThread extends Thread {
}
}
/**
* Builds the comment transmitted with a local DX Cluster spot.
*
* <p>The station locator is always retained. AirScout information is optional:
* a missing response, an empty aircraft list or an incomplete aircraft entry
* must never prevent the spot itself from being sent.</p>
*
* @param sender station for which the DX Cluster spot is generated
* @return locator with up to two optional AP entries
*/
private String buildDxClusterSpotComment(ChatMember sender) {
if (sender == null) {
return "";
}
String locator = sender.getQra() == null
? ""
: sender.getQra().trim();
AirPlaneReflectionInfo reflectionInfo =
sender.getAirPlaneReflectInfo();
if (reflectionInfo == null
|| reflectionInfo.getRisingAirplanes() == null
|| reflectionInfo.getRisingAirplanes().isEmpty()) {
return locator;
}
ArrayList<String> aircraftComments = new ArrayList<>();
int aircraftCount = Math.min(
2,
reflectionInfo.getRisingAirplanes().size()
);
for (int index = 0; index < aircraftCount; index++) {
AirPlane aircraft =
reflectionInfo.getRisingAirplanes().get(index);
if (aircraft == null) {
continue;
}
aircraftComments.add(
aircraft.getArrivingDurationMinutes()
+ "min, "
+ aircraft.getPotential()
+ "%"
);
}
if (aircraftComments.isEmpty()) {
return locator;
}
String apComment =
"AP: " + String.join("; ", aircraftComments);
return locator.isEmpty()
? apComment
: locator + " , " + apComment;
}
/**
* Method gets a String with a messagecategory-number and returns out of which of the existing categories
* (chat channels) this message/user had written from
@@ -1,6 +1,7 @@
package kst4contest.controller;
import kst4contest.logic.BandOpportunityResolver;
import kst4contest.view.map.MapCallsignRawSnapshot;
import kst4contest.logic.PropagationFrequencyResolver;
import java.util.ArrayList;
import java.util.Collections;
@@ -12,9 +13,7 @@ import java.util.function.Consumer;
import javafx.application.Platform;
import kst4contest.locatorUtils.Location;
import kst4contest.model.Band;
import kst4contest.model.ChatCategory;
import kst4contest.model.ChatMember;
import kst4contest.model.ChatPreferences;
import kst4contest.view.map.GeometryOnlyPathAnalysisService;
import kst4contest.view.map.OpenMeteoTerrainProfileProvider;
@@ -22,7 +21,6 @@ import kst4contest.view.map.PathAnalysisRequest;
import kst4contest.view.map.PathAnalysisResult;
import kst4contest.view.map.PathAnalysisService;
import kst4contest.view.map.PathGeometryUtils;
import java.util.Comparator;
import java.util.EnumSet;
import java.util.Objects;
import java.util.Set;
@@ -139,9 +137,11 @@ public final class ReachabilityService {
* @param member best matching ChatMember, may be null when only a map snapshot exists
* @param selectedSnapshot selected map snapshot
* @param fxCallback callback executed on the JavaFX thread
* @param requestedBandOverride operator-selected band, or null for automatic resolution
*/
public void requestPathAnalysisForMap(ChatMember member,
MapCallsignRawSnapshot selectedSnapshot,
Band requestedBandOverride,
Consumer<PathAnalysisResult> fxCallback) {
String ownLocator6 = normalizeLocator6(chatController.getChatPreferences().getStn_loginLocatorMainCat());
@@ -165,22 +165,23 @@ public final class ReachabilityService {
return;
}
double analysisFrequencyMHz = PathGeometryUtils.resolveAnalysisFrequencyMHz(
selectedSnapshot.lastKnownFrequenciesByBand()
);
Band analysisBand;
double analysisFrequencyMHz;
Band analysisBand = Band.fromFrequency(analysisFrequencyMHz);
if (analysisBand != null && !isUsableAutomaticBand(member, analysisBand)) {
analysisFrequencyMHz = Double.NaN;
analysisBand = null;
}
if (requestedBandOverride != null) {
/*
* An explicit operator selection has priority over automatic propagation
* resolution. Exact recent QRG information on that band is still used
* when available; otherwise the band's default analysis frequency is used.
*/
analysisBand = requestedBandOverride;
analysisFrequencyMHz =
resolveAnalysisFrequencyForBand(member, analysisBand);
} else {
PropagationFrequencyResolver.Resolution frequencyResolution =
resolveAutomaticPropagationFrequency(member);
if (!Double.isFinite(analysisFrequencyMHz)
|| analysisFrequencyMHz <= 0.0
|| analysisBand == null) {
Band fallbackBand = resolveAutoBand(member);
if (fallbackBand == null) {
if (frequencyResolution == null) {
dispatchFxCallback(
fxCallback,
PathAnalysisResult.waitingForUsableBand(
@@ -192,8 +193,9 @@ public final class ReachabilityService {
return;
}
analysisBand = fallbackBand;
analysisFrequencyMHz = resolveAnalysisFrequencyForBand(member, fallbackBand);
analysisBand = frequencyResolution.getBand();
analysisFrequencyMHz =
frequencyResolution.getAnalysisFrequencyMHz();
}
PathAnalysisRequest request = buildRequest(
@@ -236,72 +238,32 @@ public final class ReachabilityService {
}
/**
* Resolves the auto reachability band.
*
* <ol>
* <li>Use the lowest band detected in this session.</li>
* <li>If no session band exists and the station is in the microwave category, use 1296 MHz.</li>
* <li>Otherwise use 144 MHz.</li>
* </ol>
* Resolves the auto reachability band through the shared propagation
* frequency selection used by AirScout and path analysis.
*
* @param member member to inspect
* @return resolved band
*/
public Band resolveAutoBand(ChatMember member) {
EnumSet<Band> enabledBands = getEnabledStationBands();
if (enabledBands.isEmpty()) {
return null;
}
PropagationFrequencyResolver.Resolution resolution =
resolveAutomaticPropagationFrequency(member);
return resolution == null ? null : resolution.getBand();
}
List<ChatMember> variants = resolveCallsignVariants(member);
BandOpportunityResolver.Resolution resolution =
BandOpportunityResolver.resolve(variants, System.currentTimeMillis());
EnumSet<Band> availableOfferedBands = resolution.getAvailableBands();
availableOfferedBands.retainAll(enabledBands);
if (!availableOfferedBands.isEmpty()) {
return availableOfferedBands.stream()
.min(Comparator.comparingDouble(Band::getDefaultAnalysisFrequencyMHz))
.orElse(null);
}
// Known evidence exists, but every matching band is disabled or NOT QRV.
if (resolution.hasBandEvidence()) {
return null;
}
EnumSet<Band> fallbackBands = EnumSet.copyOf(enabledBands);
fallbackBands.removeAll(resolution.getNotQrvBands());
if (fallbackBands.isEmpty()) {
return null;
}
if (member != null
&& member.getChatCategory() != null
&& member.getChatCategory().getCategoryNumber() == ChatCategory.MICROWAVE
&& fallbackBands.contains(Band.B_1296)) {
return Band.B_1296;
}
if (member != null
&& member.getChatCategory() != null
&& member.getChatCategory().getCategoryNumber() == ChatCategory.FIFTYSEVENTYMHz) {
if (fallbackBands.contains(Band.B_50)) {
return Band.B_50;
}
if (fallbackBands.contains(Band.B_70)) {
return Band.B_70;
}
}
if (fallbackBands.contains(Band.B_144)) {
return Band.B_144;
}
return fallbackBands.stream()
.min(Comparator.comparingDouble(Band::getDefaultAnalysisFrequencyMHz))
.orElse(null);
/**
* Resolves one automatic band and exact analysis frequency for a station.
*
* @param member any active category variant of the target station
* @return shared propagation resolution, or {@code null} for unsupported data
*/
public PropagationFrequencyResolver.Resolution resolveAutomaticPropagationFrequency(
ChatMember member
) {
return PropagationFrequencyResolver.resolve(
resolveCallsignVariants(member),
getEnabledStationBands(),
System.currentTimeMillis()
);
}
/**
@@ -329,27 +291,7 @@ public final class ReachabilityService {
return variants.isEmpty() ? List.of(member) : variants;
}
/**
* Verifies that an automatically selected map/snapshot frequency belongs to a
* locally enabled band that is still available after NOT-QRV resolution.
* Manual UI band overrides are handled separately and are not changed here.
*/
private boolean isUsableAutomaticBand(ChatMember member, Band band) {
if (band == null || !getEnabledStationBands().contains(band)) {
return false;
}
if (member == null) {
return true;
}
BandOpportunityResolver.Resolution resolution = BandOpportunityResolver.resolve(
resolveCallsignVariants(member),
System.currentTimeMillis()
);
return resolution.getAvailableBands().contains(band);
}
/**
* Stops the background executor.
@@ -541,28 +483,7 @@ public final class ReachabilityService {
}
}
/**
* Resolves the analysis frequency from a map snapshot first, because the map
* aggregates all visible ChatMember variants and often knows the best current
* frequency per band.
*
* @param member fallback member
* @param selectedSnapshot selected map snapshot
* @return analysis frequency in MHz
*/
private double resolveAnalysisFrequencyForSnapshot(ChatMember member, MapCallsignRawSnapshot selectedSnapshot) {
if (selectedSnapshot != null) {
double snapshotFrequencyMHz =
PathGeometryUtils.resolveAnalysisFrequencyMHz(selectedSnapshot.lastKnownFrequenciesByBand());
if (Double.isFinite(snapshotFrequencyMHz) && snapshotFrequencyMHz > 0.0) {
return snapshotFrequencyMHz;
}
}
Band fallbackBand = member == null ? Band.B_144 : resolveAutoBand(member);
return resolveAnalysisFrequencyForBand(member, fallbackBand);
}
/**
* Resolves the analysis frequency for one member/band pair.
@@ -575,15 +496,28 @@ public final class ReachabilityService {
* </ol>
*/
private double resolveAnalysisFrequencyForBand(ChatMember member, Band band) {
if (member != null && member.getKnownActiveBands() != null) {
ChatMember.ActiveFrequencyInfo activeFrequencyInfo = member.getKnownActiveBands().get(band);
if (band == null) {
return Double.NaN;
}
ChatMember.ActiveFrequencyInfo latestFrequencyInfo = null;
for (ChatMember variant : resolveCallsignVariants(member)) {
ChatMember.ActiveFrequencyInfo activeFrequencyInfo =
variant.getKnownActiveBands().get(band);
if (activeFrequencyInfo != null
&& Double.isFinite(activeFrequencyInfo.frequency)
&& activeFrequencyInfo.frequency > 0.0) {
return activeFrequencyInfo.frequency;
&& activeFrequencyInfo.frequency > 0.0
&& (latestFrequencyInfo == null
|| activeFrequencyInfo.timestampEpoch > latestFrequencyInfo.timestampEpoch)) {
latestFrequencyInfo = activeFrequencyInfo;
}
}
if (latestFrequencyInfo != null) {
return latestFrequencyInfo.frequency;
}
if (member != null && member.getFrequency() != null && member.getFrequency().getValue() != null) {
double parsedFrequencyMHz = PathGeometryUtils.tryParseFrequencyMHz(member.getFrequency().getValue());
if (Double.isFinite(parsedFrequencyMHz) && parsedFrequencyMHz > 0.0) {
@@ -101,102 +101,143 @@ public class Utils4KST {
}
/**
* Normalizes a chatmembers frequency-string for cluster usage<br/>
* <b>returns a frequency String in KHz like = "144300" or "144300.0" to match DXC protocol needs</b>
* Converts a frequency detected in a chat message into the kHz representation
* used by the DX Cluster protocol.
*
* @param optionalPrefix: if there is a value like ".300", it have to be decided, wich ".300": 144.300, 432.300, 1296.300 .... prefix means for example "144."
* <p>Complete frequencies with two to five MHz digits are supported, for
* example 50.200, 144.205, 1296.338, 10368.100 and 24048.100. An optional
* second fractional group is retained as sub-kHz precision, for example
* 144.205.2 becomes 144205.2 kHz.</p>
*
* <p>Relative values such as .205 or 205 use the configured fallback-band
* prefix. The method only performs this fallback conversion after the general
* message parser has already accepted the value as a frequency.</p>
*
* @param qrgString frequency as detected by the chat parser
* @param optionalPrefix fallback MHz prefix for relative frequencies
* @return frequency in kHz for a DX Cluster spot, or an empty string if the
* value cannot be converted safely
*/
public static String normalizeFrequencyString(String qrgString, SimpleStringProperty optionalPrefix) {
// final String PTRN_QRG_CAT2 = "(([0-9]{3,4}[\\.|,| ]?[0-9]{3})([\\.|,][\\d]{1,2})?)|(([a-zA-Z][0-4]{1}[\\d]{2}\\b)([\\.|,][\\d]{1,2}\\b)?)|((\\b[0-4]{1}[\\d]{2}\\b)([\\.|,][\\d]{1,2}\\b)?)";
try {
qrgString = qrgString.replace(" ","");
} catch (Exception e) {
System.out.println("UTILS: QRG NULL, nothing to convert");
// e.printStackTrace();
public static String normalizeFrequencyString(
String qrgString,
SimpleStringProperty optionalPrefix
) {
if (qrgString == null || qrgString.isBlank()) {
return "";
}
/*
* A comma is accepted as a decimal separator. Spaces are removed so older
* stored formats such as "432 088" remain usable.
*/
String normalizedValue = qrgString
.trim()
.replace(" ", "")
.replace(',', '.');
final String PTRN_QRG_CAT2_wholeQRGMHz4Digits = "(([0-9]{4}[\\.|,| ]?[0-9]{3})([\\.|,][\\d]{1,2})?)"; //1296.300.3 etc
final String PTRN_QRG_CAT2_wholeQRGMHz3Digits = "(([0-9]{3}[\\.|,| ]?[0-9]{3})([\\.][\\d]{1,2})?)"; //144.300.3 etc
final String PTRN_QRG_CAT2_QRGwithoutPrefix = "((\\b[0-4]{1}[\\d]{2}\\b)([\\.|,][\\d]{1,2}\\b)?)"; //144.300.3 etc
/*
* Complete frequency with an explicit separator:
*
* 50.200
* 144.205
* 1296.338
* 10368.100
* 144.205.2
*/
Matcher completeFrequencyMatcher = Pattern.compile(
"^(\\d{2,5})\\.(\\d{1,3})(?:\\.(\\d{1,2}))?$"
).matcher(normalizedValue);
String stringAggregation = "";
if (testPattern(qrgString, PTRN_QRG_CAT2_wholeQRGMHz4Digits)) {//case 1296.200 or 1296.200.2 etc.
stringAggregation = qrgString;
stringAggregation = stringAggregation.replace(".","");
stringAggregation = stringAggregation.replace(",","");
stringAggregation = stringAggregation.replace(" ", "");
if (stringAggregation.length() == 8) {
String stringAggregationNew = stringAggregation.substring(0, stringAggregation.length()-1) + "." + stringAggregation.substring(stringAggregation.length()-1, stringAggregation.length());
stringAggregation = stringAggregationNew + ".0";
return stringAggregation;
} else if (stringAggregation.length() == 9) {
String stringAggregationNew = stringAggregation.substring(0, stringAggregation.length()-2) + "." + stringAggregation.substring(stringAggregation.length()-2, stringAggregation.length());
stringAggregation = stringAggregationNew;
return stringAggregation;
}
} else
if (testPattern(qrgString, PTRN_QRG_CAT2_wholeQRGMHz3Digits)) { //case 144.300 or 144.300.2
stringAggregation = qrgString;
stringAggregation = stringAggregation.replace(".","");
stringAggregation = stringAggregation.replace(",","");
stringAggregation = stringAggregation.replace(" ", "");
if (stringAggregation.length() == 6) {
stringAggregation = stringAggregation + ".0";
return stringAggregation;
}
if (stringAggregation.length() == 7) {
String stringAggregationNew = stringAggregation.substring(0, stringAggregation.length()-1) + "." + stringAggregation.substring(stringAggregation.length()-1, stringAggregation.length());
stringAggregation = stringAggregationNew + ".0";
return stringAggregation;
} else if (stringAggregation.length() == 8) {
String stringAggregationNew = stringAggregation.substring(0, stringAggregation.length()-2) + "." + stringAggregation.substring(stringAggregation.length()-2, stringAggregation.length());
stringAggregation = stringAggregationNew;
return stringAggregation;
}
}
else
if (testPattern(qrgString, PTRN_QRG_CAT2_QRGwithoutPrefix)) { //case ".050 or .300 or something like that"
stringAggregation = qrgString;
stringAggregation = stringAggregation.replace(".", "");
stringAggregation = stringAggregation.replace(",", "");
stringAggregation = stringAggregation.replace(" ", "");
if (stringAggregation.length() == 3) { // like 050 or 300
String stringAggregationNew = optionalPrefix.getValue() + stringAggregation;
stringAggregation = stringAggregationNew + ".0";
return stringAggregation;
} else if (stringAggregation.length() == 4) { //like 050.2 --> 0502
stringAggregation = optionalPrefix.getValue() + stringAggregation;
String stringAggregationNew = stringAggregation.substring(0, stringAggregation.length() - 1) + "." + stringAggregation.substring(stringAggregation.length() - 1, stringAggregation.length());
stringAggregation = stringAggregationNew;
return stringAggregation;
} else if (stringAggregation.length() == 5) { //like 050.20 --> 05020
stringAggregation = optionalPrefix.getValue() + stringAggregation;
String stringAggregationNew = stringAggregation.substring(0, stringAggregation.length() - 2) + "." + stringAggregation.substring(stringAggregation.length() - 2, stringAggregation.length());
stringAggregation = stringAggregationNew;
return stringAggregation;
}
if (completeFrequencyMatcher.matches()) {
return formatDxClusterFrequency(
completeFrequencyMatcher.group(1),
completeFrequencyMatcher.group(2),
completeFrequencyMatcher.group(3)
);
}
return stringAggregation; //if nothing else helps
/*
* Compact complete frequency retained for compatibility:
*
* 144205
* 1296338
* 10368100
* 432088.2
*/
Matcher compactFrequencyMatcher = Pattern.compile(
"^(\\d{2,5})(\\d{3})(?:\\.(\\d{1,2}))?$"
).matcher(normalizedValue);
if (compactFrequencyMatcher.matches()) {
return formatDxClusterFrequency(
compactFrequencyMatcher.group(1),
compactFrequencyMatcher.group(2),
compactFrequencyMatcher.group(3)
);
}
/*
* Relative frequency. Values above 499 are deliberately rejected, matching
* the previous behaviour and preventing a report such as 599 from becoming
* a plausible-looking cluster frequency.
*/
Matcher relativeFrequencyMatcher = Pattern.compile(
"^\\.?([0-4]\\d{2})(?:\\.(\\d{1,2}))?$"
).matcher(normalizedValue);
if (!relativeFrequencyMatcher.matches()) {
return "";
}
String fallbackPrefix = optionalPrefix == null
? null
: optionalPrefix.getValue();
if (fallbackPrefix == null) {
return "";
}
fallbackPrefix = fallbackPrefix.trim();
if (!fallbackPrefix.matches("\\d{2,5}")) {
return "";
}
return formatDxClusterFrequency(
fallbackPrefix,
relativeFrequencyMatcher.group(1),
relativeFrequencyMatcher.group(2)
);
}
/**
* Formats an MHz part, a fractional MHz part and optional sub-kHz digits as a
* DX Cluster frequency in kHz.
*
* <p>The fractional MHz part is padded on the right because 144.2 means
* 144.200 MHz, while 144.21 means 144.210 MHz.</p>
*
* @param mhzPart complete MHz part
* @param fractionalMhzPart one to three digits following the first separator
* @param subKhzPart optional digits following a second separator
* @return DX Cluster frequency in kHz
*/
private static String formatDxClusterFrequency(
String mhzPart,
String fractionalMhzPart,
String subKhzPart
) {
String paddedFraction =
(fractionalMhzPart + "000").substring(0, 3);
String subKhz = subKhzPart == null
? "0"
: subKhzPart;
return mhzPart
+ paddedFraction
+ "."
+ subKhz;
}
}
@@ -113,12 +113,32 @@ public final class BandOpportunityResolver {
return detectedBands;
}
/*
* Explicit band descriptions:
* 2m, 70cm, 23cm, 432, 1296, ...
*/
for (Map.Entry<Band, Pattern> entry : STATION_NAME_BAND_PATTERNS.entrySet()) {
if (entry.getValue().matcher(stationName).find()) {
detectedBands.add(entry.getKey());
}
}
/*
* Explicit full QRGs in name field:
* 432.357 -> 432 MHz
* 1296.210 -> 1296 MHz
* etc.
*/
for (FrequencyTextParser.DetectedFrequency detectedFrequency
: FrequencyTextParser.findExplicitFrequencies(
stationName
)) {
detectedBands.add(
detectedFrequency.getBand()
);
}
return detectedBands;
}
@@ -0,0 +1,191 @@
package kst4contest.logic;
import kst4contest.model.Band;
import java.util.ArrayList;
import java.util.LinkedHashMap;
import java.util.List;
import java.util.Map;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
/**
* Common parser for explicit amateur-radio frequencies embedded in text.
*
* <p>This parser deliberately handles only complete frequencies such as
* 144.300, 432.357 or 10368.100. Relative forms such as ".210" or ambiguous
* bare values such as "210" require additional message context and remain the
* responsibility of the chat-message parser.</p>
*/
public final class FrequencyTextParser {
/*
* Examples:
* 50.150
* 144.300
* 432,357
* 10368.100
* 144.300.03
*
* At least two digits are required before the decimal separator. This
* intentionally prevents "1.2" from being interpreted as a frequency.
*/
private static final Pattern EXPLICIT_FREQUENCY_PATTERN = Pattern.compile(
"(?<![A-Z0-9])"
+ "(\\d{2,5}[.,]\\d{1,3}(?:[.,]\\d{1,3})?)"
+ "(?!\\d)",
Pattern.CASE_INSENSITIVE
);
private FrequencyTextParser() {
}
/**
* Finds all distinct explicit frequencies that fall into one of the bands
* supported by {@link Band}.
*/
public static List<DetectedFrequency> findExplicitFrequencies(String text) {
if (text == null || text.isBlank()) {
return List.of();
}
Matcher matcher = EXPLICIT_FREQUENCY_PATTERN.matcher(text);
Map<String, DetectedFrequency> uniqueFrequencies =
new LinkedHashMap<>();
while (matcher.find()) {
DetectedFrequency detected =
parseExplicitFrequency(matcher.group(1));
if (detected == null) {
continue;
}
String uniqueKey =
detected.getBand().name()
+ "|"
+ Double.toString(
detected.getFrequencyMHz()
);
uniqueFrequencies.putIfAbsent(
uniqueKey,
detected
);
}
return List.copyOf(
new ArrayList<>(uniqueFrequencies.values())
);
}
/**
* Parses one complete frequency.
*
* @return detected band/frequency or {@code null} when the value is invalid
* or outside the supported amateur bands
*/
public static DetectedFrequency parseExplicitFrequency(
String rawFrequency
) {
if (rawFrequency == null || rawFrequency.isBlank()) {
return null;
}
String normalized =
normalizeFrequencyString(
rawFrequency
.trim()
.replace(',', '.')
);
try {
double frequencyMHz =
Double.parseDouble(normalized);
if (!Double.isFinite(frequencyMHz)) {
return null;
}
Band band =
Band.fromFrequency(frequencyMHz);
if (band == null) {
return null;
}
return new DetectedFrequency(
band,
frequencyMHz,
rawFrequency.trim()
);
} catch (NumberFormatException ignored) {
return null;
}
}
/**
* Normalizes KST-style frequency strings with an optional second decimal
* separator.
*
* Examples:
* 144.300.03 -> 144.30003
* 144.300 -> 144.300
*/
private static String normalizeFrequencyString(
String rawInput
) {
int firstDotIndex = rawInput.indexOf('.');
if (firstDotIndex < 0) {
return rawInput;
}
String decimalPart =
rawInput.substring(firstDotIndex + 1);
if (!decimalPart.contains(".")) {
return rawInput;
}
decimalPart =
decimalPart.replace(".", "");
return rawInput.substring(0, firstDotIndex + 1)
+ decimalPart;
}
/**
* Immutable result of one explicit-frequency detection.
*/
public static final class DetectedFrequency {
private final Band band;
private final double frequencyMHz;
private final String sourceText;
private DetectedFrequency(
Band band,
double frequencyMHz,
String sourceText
) {
this.band = band;
this.frequencyMHz = frequencyMHz;
this.sourceText = sourceText;
}
public Band getBand() {
return band;
}
public double getFrequencyMHz() {
return frequencyMHz;
}
public String getSourceText() {
return sourceText;
}
}
}
@@ -83,12 +83,13 @@ public class PriorityCalculator {
// --------------------------------------------------------------------
double score = 100.0;
// if (!member.isWorked()) {
// score += 200.0;
// }
//"worked" for scoring is derived ONLY from per-band flags (worked144/432/...)
// EnumSet<Band> workedBandsForScoring = getWorkedBands(member);
/*
* A manual Sked-fail mark represents an explicit operator decision. The
* penalty is therefore applied after all positive contributions, including
* an imminent sked. Applying it earlier would allow the later sked boost to
* almost completely cancel the failure mark.
*/
boolean manualSkedFailed = false;
if (workedBandsForScoring.isEmpty()) {
score += 200.0; // never worked on any supported band -> higher priority
@@ -190,9 +191,11 @@ public class PriorityCalculator {
}
// Manual sked fail (path likely bad) => strong, permanent penalty until reset
if (mx.manualSkedFailed) {
score *= 0.15;
}
/*
* Remember the explicit failure state here. The actual penalty is applied
* after the sked contribution has been calculated.
*/
manualSkedFailed = mx.manualSkedFailed;
}
}
@@ -226,10 +229,25 @@ public class PriorityCalculator {
// --------------------------------------------------------------------
// 8) Legacy penalty: failed attempts in ChatMember
// --------------------------------------------------------------------
// --------------------------------------------------------------------
// 8) Legacy penalty: failed attempts in ChatMember
// --------------------------------------------------------------------
if (member.getFailedQSOAttempts() > 0) {
score = score / (member.getFailedQSOAttempts() + 1);
}
// --------------------------------------------------------------------
// 9) Explicit operator override: manual Sked fail
// --------------------------------------------------------------------
if (manualSkedFailed) {
/*
* Apply the penalty to the complete result. This includes an imminent
* sked and prevents its strong time-dependent boost from cancelling the
* operator's explicit failure assessment.
*/
score *= 0.15;
}
return Math.max(0.0, score);
}
@@ -0,0 +1,381 @@
package kst4contest.logic;
import kst4contest.model.Band;
import kst4contest.model.ChatCategory;
import kst4contest.model.ChatMember;
import java.util.Collection;
import java.util.Comparator;
import java.util.EnumSet;
import java.util.List;
/**
* Selects one realistic propagation frequency for a station.
*
* <p>The same resolution is used by AirScout and by the internal path analysis.
* Only the chat categories supported by these features participate. This keeps
* unrelated KST categories from silently falling back to 144 MHz.</p>
*/
public final class PropagationFrequencyResolver {
// private static final double DUAL_VUHF_MICROWAVE_FALLBACK_MHZ = 430.0;
private PropagationFrequencyResolver() {
}
/** Explains why a frequency was selected. */
public enum Source {
CURRENT_QRG,
STATION_NAME_QRG,
STATION_NAME,
DUAL_CATEGORY_FALLBACK,
CHAT_CATEGORY
}
/**
* Resolves the frequency from all active category variants of one base
* callsign.
*
* <ol>
* <li>Most recently detected QRG</li>
* <li>Lowest band explicitly named by the station</li>
* <li>432 MHz if the station is present in VUHF and Microwave</li>
* <li>Lowest usable fallback band of the supported chat category</li>
* </ol>
*
* <p>Locally disabled and manually excluded bands are never selected.</p>
*
* @param variants active category variants of one callsign
* @param enabledBands bands enabled for the local station
* @param nowEpochMs current time used for the QRG age check
* @return one resolution, or {@code null} if no safe choice exists
*/
public static Resolution resolve(Collection<ChatMember> variants,
EnumSet<Band> enabledBands,
long nowEpochMs) {
if (variants == null || variants.isEmpty()
|| enabledBands == null || enabledBands.isEmpty()) {
return null;
}
List<ChatMember> supportedVariants = variants.stream()
.filter(PropagationFrequencyResolver::isSupportedVariant)
.toList();
if (supportedVariants.isEmpty()) {
return null;
}
BandOpportunityResolver.Resolution opportunityResolution =
BandOpportunityResolver.resolve(supportedVariants, nowEpochMs);
EnumSet<Band> usableBands = EnumSet.copyOf(enabledBands);
usableBands.removeAll(opportunityResolution.getNotQrvBands());
if (usableBands.isEmpty()) {
return null;
}
FrequencyCandidate latestQrg = findLatestQrg(
supportedVariants,
usableBands,
nowEpochMs
);
if (latestQrg != null) {
return new Resolution(
latestQrg.band,
latestQrg.frequencyMHz,
Source.CURRENT_QRG
);
}
FrequencyCandidate stationNameQrg =
findUniqueStationNameQrg(
supportedVariants,
usableBands
);
if (stationNameQrg != null) {
return new Resolution(
stationNameQrg.band,
stationNameQrg.frequencyMHz,
Source.STATION_NAME_QRG
);
}
EnumSet<Band> nameBands = EnumSet.noneOf(Band.class);
for (ChatMember variant : supportedVariants) {
nameBands.addAll(
BandOpportunityResolver.detectBandsFromStationName(variant.getName())
);
}
nameBands.retainAll(usableBands);
Band nameBand = lowestBand(nameBands);
if (nameBand != null) {
return new Resolution(
nameBand,
nameBand.getDefaultAnalysisFrequencyMHz(),
Source.STATION_NAME
);
}
EnumSet<SupportedCategory> categories = collectSupportedCategories(supportedVariants);
if (categories.contains(SupportedCategory.VUHF)
&& categories.contains(SupportedCategory.MICROWAVE)
&& usableBands.contains(Band.B_432)) {
return new Resolution(
Band.B_432,
Band.B_432.getDefaultAnalysisFrequencyMHz(),
Source.DUAL_CATEGORY_FALLBACK
);
}
EnumSet<Band> categoryBands = EnumSet.noneOf(Band.class);
for (SupportedCategory category : categories) {
categoryBands.addAll(category.fallbackBands);
}
categoryBands.retainAll(usableBands);
Band categoryBand = lowestBand(categoryBands);
if (categoryBand == null) {
return null;
}
return new Resolution(
categoryBand,
categoryBand.getDefaultAnalysisFrequencyMHz(),
Source.CHAT_CATEGORY
);
}
private static FrequencyCandidate findLatestQrg(List<ChatMember> variants,
EnumSet<Band> usableBands,
long nowEpochMs) {
FrequencyCandidate latest = null;
for (ChatMember variant : variants) {
for (var entry : variant.getKnownActiveBands().entrySet()) {
Band band = entry.getKey();
ChatMember.ActiveFrequencyInfo info = entry.getValue();
if (band == null || info == null || !usableBands.contains(band)) {
continue;
}
long ageMs = nowEpochMs - info.timestampEpoch;
if (ageMs < 0L
|| ageMs > BandOpportunityResolver.RECENT_DYNAMIC_EVIDENCE_MAX_AGE_MS
|| !Double.isFinite(info.frequency)
|| !band.isPlausible(info.frequency)) {
continue;
}
if (latest == null || info.timestampEpoch > latest.timestampEpochMs) {
latest = new FrequencyCandidate(
band,
info.frequency,
info.timestampEpoch
);
}
}
}
return latest;
}
/**
* Resolves one exact station-name QRG only when the evidence is unambiguous.
*
* <p>The same QRG repeated in several category variants counts only once.
* If different explicit QRGs are advertised, no run frequency is guessed and
* the caller continues with normal band-name/category resolution.</p>
*/
private static FrequencyCandidate findUniqueStationNameQrg(
List<ChatMember> variants,
EnumSet<Band> usableBands
) {
java.util.LinkedHashMap<String, FrequencyCandidate> uniqueCandidates =
new java.util.LinkedHashMap<>();
for (ChatMember variant : variants) {
if (variant == null) {
continue;
}
for (FrequencyTextParser.DetectedFrequency detectedFrequency
: FrequencyTextParser.findExplicitFrequencies(
variant.getName()
)) {
Band band =
detectedFrequency.getBand();
if (!usableBands.contains(band)) {
continue;
}
double frequencyMHz =
detectedFrequency.getFrequencyMHz();
String key =
band.name()
+ "|"
+ Double.toString(frequencyMHz);
uniqueCandidates.putIfAbsent(
key,
new FrequencyCandidate(
band,
frequencyMHz,
Long.MIN_VALUE
)
);
/*
* More than one different exact QRG means that we cannot safely
* identify one run frequency.
*/
if (uniqueCandidates.size() > 1) {
return null;
}
}
}
return uniqueCandidates.size() == 1
? uniqueCandidates.values()
.iterator()
.next()
: null;
}
private static boolean isSupportedVariant(ChatMember member) {
if (member == null || member.getChatCategory() == null) {
return false;
}
int categoryNumber = member.getChatCategory().getCategoryNumber();
return categoryNumber == ChatCategory.FIFTYSEVENTYMHz
|| categoryNumber == ChatCategory.VUHF
|| categoryNumber == ChatCategory.MICROWAVE
|| categoryNumber == ChatCategory.EMEJT65;
}
private static EnumSet<SupportedCategory> collectSupportedCategories(
List<ChatMember> variants
) {
EnumSet<SupportedCategory> categories = EnumSet.noneOf(SupportedCategory.class);
for (ChatMember variant : variants) {
int categoryNumber = variant.getChatCategory().getCategoryNumber();
if (categoryNumber == ChatCategory.FIFTYSEVENTYMHz) {
categories.add(SupportedCategory.FIFTY_SEVENTY);
} else if (categoryNumber == ChatCategory.VUHF) {
categories.add(SupportedCategory.VUHF);
} else if (categoryNumber == ChatCategory.MICROWAVE) {
categories.add(SupportedCategory.MICROWAVE);
} else if (categoryNumber == ChatCategory.EMEJT65) {
categories.add(SupportedCategory.EME);
}
}
return categories;
}
private static Band lowestBand(Collection<Band> bands) {
if (bands == null || bands.isEmpty()) {
return null;
}
return bands.stream()
.min(Comparator.comparingDouble(Band::getDefaultAnalysisFrequencyMHz))
.orElse(null);
}
private enum SupportedCategory {
FIFTY_SEVENTY(EnumSet.of(Band.B_50, Band.B_70)),
VUHF(EnumSet.of(Band.B_144, Band.B_432)),
MICROWAVE(EnumSet.of(
Band.B_1296,
Band.B_2320,
Band.B_3400,
Band.B_5760,
Band.B_10G,
Band.B_24G
)),
EME(EnumSet.of(
Band.B_144,
Band.B_432,
Band.B_1296,
Band.B_2320,
Band.B_3400,
Band.B_5760,
Band.B_10G,
Band.B_24G
));
private final EnumSet<Band> fallbackBands;
SupportedCategory(EnumSet<Band> fallbackBands) {
this.fallbackBands = fallbackBands;
}
}
private static final class FrequencyCandidate {
private final Band band;
private final double frequencyMHz;
private final long timestampEpochMs;
private FrequencyCandidate(Band band,
double frequencyMHz,
long timestampEpochMs) {
this.band = band;
this.frequencyMHz = frequencyMHz;
this.timestampEpochMs = timestampEpochMs;
}
}
/** Immutable selected band/frequency pair. */
public static final class Resolution {
private final Band band;
private final double analysisFrequencyMHz;
private final Source source;
private Resolution(Band band,
double analysisFrequencyMHz,
Source source) {
this.band = band;
this.analysisFrequencyMHz = analysisFrequencyMHz;
this.source = source;
}
public Band getBand() {
return band;
}
public double getAnalysisFrequencyMHz() {
return analysisFrequencyMHz;
}
public Source getSource() {
return source;
}
/**
* Converts MHz to AirScout's 100-Hz protocol unit.
*
* @return integer protocol value, for example 1442100 for 144.210 MHz
*/
public String getAirScoutBandValue() {
return Long.toString(Math.round(analysisFrequencyMHz * 10_000.0));
}
}
}
@@ -518,6 +518,7 @@ public class ChatMember {
this.frequency = frequency;
}
public long getActivityTimeLastInEpoch() {
return activityTimeLastInEpoch;
}
@@ -595,6 +596,40 @@ public class ChatMember {
}
/**
* Initializes the compatibility frequency only when no frequency is known yet.
*
* <p>This is used for an explicit QRG contained in the ON4KST station name.
* A subsequently detected chat QRG may overwrite this initial value, but a
* station-name QRG never replaces an already known frequency.</p>
*
* @param frequencyMhz explicit station-name frequency
* @return true when the frequency was initialized
*/
public boolean initializeFrequencyIfEmpty(double frequencyMhz) {
if (!Double.isFinite(frequencyMhz)
|| frequencyMhz <= 0.0) {
return false;
}
if (frequency == null) {
frequency = new SimpleStringProperty();
}
String currentFrequency = frequency.get();
if (currentFrequency != null
&& !currentFrequency.isBlank()) {
return false;
}
frequency.set(
Double.toString(frequencyMhz)
);
return true;
}
/**
* Sets all worked information of this object to false. Scope: GUI, Reset Button
* for worked info, called by appcontroller
@@ -245,6 +245,7 @@ public class ChatPreferences {
boolean AirScout_asUDPListenerEnabled = true;
String AirScout_asServerNameString = "AS";
String AirScout_asClientNameString = "KST";
boolean AirScout_autoBandSelectionEnabled = true;
String AirScout_asBandString = "1440000";
int AirScout_asCommunicationPort = 9872;
@@ -1004,6 +1005,16 @@ public class ChatPreferences {
return AirScout_asBandString;
}
public boolean isAirScout_autoBandSelectionEnabled() {
return AirScout_autoBandSelectionEnabled;
}
public void setAirScout_autoBandSelectionEnabled(
boolean airScoutAutoBandSelectionEnabled
) {
AirScout_autoBandSelectionEnabled = airScoutAutoBandSelectionEnabled;
}
public void setAirScout_asBandString(String airScout_asBandString) {
if (airScout_asBandString == null) {
AirScout_asBandString = "1440000";
@@ -1695,6 +1706,13 @@ public class ChatPreferences {
asQry_airScoutUDPPort.setTextContent(this.getAirScout_asCommunicationPort()+"");
AirScoutQuerier.appendChild(asQry_airScoutUDPPort);
Element asQry_airScoutAutoBandSelectionEnabled =
doc.createElement("asQry_airScoutAutoBandSelectionEnabled");
asQry_airScoutAutoBandSelectionEnabled.setTextContent(
Boolean.toString(this.isAirScout_autoBandSelectionEnabled())
);
AirScoutQuerier.appendChild(asQry_airScoutAutoBandSelectionEnabled);
Element asQry_airScoutBandValue = doc.createElement("asQry_airScoutBandValue");
asQry_airScoutBandValue.setTextContent(this.getAirScout_asBandString());
AirScoutQuerier.appendChild(asQry_airScoutBandValue);
@@ -2508,6 +2526,14 @@ public class ChatPreferences {
)
);
setAirScout_autoBandSelectionEnabled(
getBoolean(
airScoutEl,
AirScout_autoBandSelectionEnabled,
"asQry_airScoutAutoBandSelectionEnabled"
)
);
setAirScout_asBandString(
getText(
airScoutEl,
@@ -2525,6 +2551,8 @@ public class ChatPreferences {
+ AirScout_asClientNameString
+ ", port="
+ AirScout_asCommunicationPort
+ ", automatic band selection="
+ AirScout_autoBandSelectionEnabled
+ ", band="
+ AirScout_asBandString
);
@@ -0,0 +1,123 @@
package kst4contest.test;
import kst4contest.logic.FrequencyTextParser;
import kst4contest.model.Band;
import org.junit.jupiter.api.Test;
import java.util.List;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;
class FrequencyTextParserTest {
@Test
void detectsExplicitStationNameFrequencies() {
List<FrequencyTextParser.DetectedFrequency> detected =
FrequencyTextParser.findExplicitFrequencies(
"Phil 432.357"
);
assertEquals(1, detected.size());
assertEquals(
Band.B_432,
detected.get(0).getBand()
);
assertEquals(
432.357,
detected.get(0).getFrequencyMHz(),
0.000_001
);
}
@Test
void detectsCommaAndMicrowaveFrequencies() {
List<FrequencyTextParser.DetectedFrequency> detected =
FrequencyTextParser.findExplicitFrequencies(
"QRV 1296,210 / 10368.100"
);
assertEquals(2, detected.size());
assertEquals(
Band.B_1296,
detected.get(0).getBand()
);
assertEquals(
Band.B_10G,
detected.get(1).getBand()
);
}
@Test
void detectsFiftyAndSeventyMhzFrequencies() {
assertEquals(
Band.B_50,
FrequencyTextParser
.findExplicitFrequencies("50.150")
.get(0)
.getBand()
);
assertEquals(
Band.B_70,
FrequencyTextParser
.findExplicitFrequencies("70.200")
.get(0)
.getBand()
);
}
@Test
void ignoresRelativeAndAmbiguousValues() {
assertTrue(
FrequencyTextParser
.findExplicitFrequencies(
"Mike .180"
)
.isEmpty()
);
assertTrue(
FrequencyTextParser
.findExplicitFrequencies(
"Mike 180"
)
.isEmpty()
);
assertTrue(
FrequencyTextParser
.findExplicitFrequencies(
"David 1.2"
)
.isEmpty()
);
assertTrue(
FrequencyTextParser
.findExplicitFrequencies(
"RST 599"
)
.isEmpty()
);
}
@Test
void normalizesSubKhzNotation() {
FrequencyTextParser.DetectedFrequency detected =
FrequencyTextParser
.findExplicitFrequencies(
"144.300.03"
)
.get(0);
assertEquals(Band.B_144, detected.getBand());
assertEquals(
144.30003,
detected.getFrequencyMHz(),
0.000_001
);
}
}
@@ -0,0 +1,63 @@
package kst4contest.test;
import javafx.beans.property.SimpleStringProperty;
import kst4contest.controller.Utils4KST;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
class Utils4KSTFrequencyTest {
@Test
void convertsCompleteFrequenciesAcrossAllSupportedPrefixLengths() {
assertEquals("50200.0", convert("50.200", "144"));
assertEquals("70250.0", convert("70,250", "144"));
assertEquals("144205.0", convert("144.205", "432"));
assertEquals("432088.0", convert("432.088", "144"));
assertEquals("1296338.0", convert("1296.338", "144"));
assertEquals("10368100.0", convert("10368.100", "144"));
assertEquals("24048100.0", convert("24048.100", "144"));
}
@Test
void retainsSubKhzPrecision() {
assertEquals("144205.2", convert("144.205.2", "432"));
assertEquals("1296338.25", convert("1296.338.25", "144"));
}
@Test
void convertsCompactLegacyFormats() {
assertEquals("432088.0", convert("432088", "144"));
assertEquals("10368100.0", convert("10368100", "144"));
assertEquals("432088.2", convert("432088.2", "144"));
assertEquals("432088.0", convert("432 088", "144"));
}
@Test
void appliesFallbackOnlyToRelativeFrequencies() {
assertEquals("432205.0", convert(".205", "432"));
assertEquals("144205.0", convert("205", "144"));
assertEquals("10368300.0", convert(".300", "10368"));
}
@Test
void rejectsMissingOrUnsupportedValues() {
assertEquals("", convert(null, "144"));
assertEquals("", convert("", "144"));
assertEquals("", convert("not-a-frequency", "144"));
assertEquals("", convert("599", "144"));
assertEquals("", convert(".205", null));
assertEquals("", convert(".205", "invalid"));
}
private String convert(String frequency, String fallbackPrefix) {
SimpleStringProperty fallback = fallbackPrefix == null
? null
: new SimpleStringProperty(fallbackPrefix);
return Utils4KST.normalizeFrequencyString(
frequency,
fallback
);
}
}
+55 -3
View File
@@ -1,14 +1,66 @@
package kst4contest.view;
import kst4contest.controller.ChatController;
import kst4contest.model.ChatMember;
import java.util.function.Predicate;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import javafx.scene.image.Image;
import javafx.stage.Stage;
import java.net.URL;
public class GuiUtils {
private static final String APPLICATION_ICON_RESOURCE = "/icons/kst4contest.png";
private static Image applicationIcon;
/**
* Applies the common KST4Contest application icon to a JavaFX stage.
*
* <p>The icon is loaded only once and reused for all application windows.
* A missing icon resource must never prevent a window from opening.</p>
*
* @param stage stage that should receive the application icon
*/
public static void applyApplicationIcon(Stage stage) {
if (stage == null) {
return;
}
Image icon = getApplicationIcon();
if (icon != null && !stage.getIcons().contains(icon)) {
stage.getIcons().add(icon);
}
}
/**
* Loads and caches the common KST4Contest application icon.
*
* @return application icon or null if the resource is unavailable
*/
private static Image getApplicationIcon() {
if (applicationIcon != null) {
return applicationIcon;
}
URL iconUrl = GuiUtils.class.getResource(APPLICATION_ICON_RESOURCE);
if (iconUrl == null) {
System.err.println(
"Application icon resource not found: "
+ APPLICATION_ICON_RESOURCE
);
return null;
}
applicationIcon = new Image(iconUrl.toExternalForm());
return applicationIcon;
}
private static final String PTRN_CALLSIGNSYNTAX = "^(?:[A-Z]{1,2}[0-9]|[0-9][A-Z])[0-9A-Z]{1,3}$";
/**
* Checks wheter the input value of the String is numeric or not, true if yes
@@ -1,6 +1,7 @@
package kst4contest.view;
import kst4contest.utils.VersionUtils;
import javafx.scene.image.Image;
import java.io.File;
import java.io.IOException;
import java.net.URISyntaxException;
@@ -178,7 +179,8 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
chatcontroller,
tbl_chatMember,
stationMapView,
this::focusChatMemberAndPrepareCq
this::focusChatMemberAndPrepareCq,
() -> selectedReachabilityBandOverride
);
stationMapBridge.install();
}
@@ -4386,10 +4388,10 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
/**
* Resolves and selects a priority candidate.
*
* If the station is currently visible in the member table, selecting it there is
* preferred because the existing table-selection listener then keeps the rest of
* the UI in sync. If the station is filtered out, we still show FurtherInfo and
* prepare the /cq text so the priority list remains useful with active filters.
* <p>The common selection helper is used deliberately. It updates Further Info,
* prepares the directed message and selects the corresponding table row when
* the row is currently visible. A candidate hidden by an active table filter
* remains usable without changing or resetting that filter.</p>
*/
private void selectTopCandidate(
kst4contest.controller.ScoreService.TopCandidate candidate,
@@ -4406,25 +4408,17 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
return;
}
// if (tbl_chatMember.getItems().contains(resolved)) {
// tbl_chatMember.getSelectionModel().select(resolved);
// tbl_chatMember.scrollTo(resolved);
// } else {
// selectedCallSignInfoStageChatMember = resolved;
// chatcontroller.getScoreService().setSelectedChatMember(selectedCallSignInfoStageChatMember);
//
// selectedCallSignFurtherInfoPane.getChildren().setAll(generateFurtherInfoAbtSelectedCallsignBP(resolved));
// txt_chatMessageUserInput.clear();
// txt_chatMessageUserInput.setText("/cq " + resolved.getCallSign() + " ");
// txt_chatMessageUserInput.requestFocus();
// txt_chatMessageUserInput.selectEnd();
// }
tbl_chatMember.getSelectionModel().select(resolved); //new mechanic for selectionchange events due to textfield
//manipulation...
// Keep ScoreService selection in sync even if the visible table selection path was used.
chatcontroller.getScoreService().setSelectedChatMember(resolved);
/*
* This is an explicit operator action and therefore follows the same path
* as a timeline click. The exact callsign and category stored in the
* TopCandidate remain authoritative.
*
* focusChatMemberAndPrepareCq() also handles candidates which are currently
* hidden by a FilteredList. In that case the table row cannot be selected,
* but Further Info, ScoreService selection and the prepared /cq message are
* still updated.
*/
focusChatMemberAndPrepareCq(resolved);
}
/**
@@ -4438,6 +4432,8 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
TextField txt_chatMessageUserInput
) {
Stage stage = new Stage();
GuiUtils.applyApplicationIcon(stage);
stage.setTitle("Top priority candidates");
ListView<kst4contest.controller.ScoreService.TopCandidate> listView = new ListView<>();
@@ -6375,7 +6371,7 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
@Override
public void start(Stage primaryStage) throws InterruptedException, IOException, URISyntaxException {
GuiUtils.applyApplicationIcon(primaryStage);
VBox pnl_inputAndSendButtons = new VBox(); //gets the sendtext field, send button and the timeline
timelineView = new TimelineView();
@@ -7958,6 +7954,15 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
Band selectedBand = resolveReachabilityBandForUi(selectedMember);
chatcontroller.getReachabilityService().calculateSelectedStationOnDemand(selectedMember, selectedBand);
/*
* If the map is already initialized, make it request the same operator-selected
* band. ReachabilityService deduplicates the identical calculation key, so this
* attaches the map callback without causing a second terrain API request.
*/
if (stationMapBridge != null) {
stationMapBridge.requestSelectedPathAnalysisRefresh();
}
}
});
@@ -7970,7 +7975,10 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
cmbReachabilityBand.getItems().add(band.getDisplayLabel());
}
cmbReachabilityBand.getSelectionModel().select("Auto");
cmbReachabilityBand.setTooltip(new Tooltip("Reachability band for Tropo column/filter. Auto uses the station's lowest session band."));
cmbReachabilityBand.setTooltip(new Tooltip(
"Reachability band for Tropo column/filter. Auto uses the current "
+ "QRG, station-name hints and the supported chat category."
));
cmbReachabilityBand.setOnAction(new EventHandler<ActionEvent>() {
@Override
public void handle(ActionEvent event) {
@@ -8492,6 +8500,8 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
* Window Cluster & qso of the other
*/
clusterAndQSOMonStage = new Stage();
GuiUtils.applyApplicationIcon(clusterAndQSOMonStage);
// clusterAndQSOMonStage.initStyle(StageStyle.UTILITY);
clusterAndQSOMonStage.setTitle("Cluster & QSO of the other");
SplitPane pnl_directedMSGWin = new SplitPane();
@@ -8545,6 +8555,7 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
* Window updates
*/
stage_updateStage = new Stage();
GuiUtils.applyApplicationIcon(stage_updateStage);
stage_updateStage.setTitle("Update information");
@@ -8682,6 +8693,8 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
*
****************************************************************************/
settingsStage = new Stage();
GuiUtils.applyApplicationIcon(settingsStage);
settingsStage.setTitle("Change Client Settings");
BorderPane optionsPanel = new BorderPane();
@@ -9038,6 +9051,7 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
TextField txtFldstn_pathAnalysisDemRootDirectory =
new TextField(this.chatcontroller.getChatPreferences().getStn_pathAnalysisDemRootDirectory());
txtFldstn_pathAnalysisDemRootDirectory.setDisable(true);
txtFldstn_pathAnalysisDemRootDirectory.setFocusTraversable(false);
txtFldstn_pathAnalysisDemRootDirectory.setTooltip(new Tooltip(
"Root directory that contains locally extracted Copernicus GLO-30 DEM tiles.\n" +
@@ -9058,6 +9072,7 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
OfflineDemImportService offlineDemImportService = new OfflineDemImportService();
Button btnUseDefaultDemDirectory = new Button("Default");
btnUseDefaultDemDirectory.setDisable(true);
btnUseDefaultDemDirectory.setFocusTraversable(false);
btnUseDefaultDemDirectory.setTooltip(new Tooltip(
"Creates and uses the default local Copernicus DEM directory below .praktiKST.\n" +
@@ -9087,6 +9102,7 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
});
Button btnImportDemTiles = new Button("Import tiles...");
btnImportDemTiles.setDisable(true);
btnImportDemTiles.setFocusTraversable(false);
btnImportDemTiles.setTooltip(new Tooltip(
"Copies manually selected Copernicus *_DEM.tif files into the configured DEM root directory.\n" +
@@ -9938,8 +9954,11 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
Label lblASUdpPort =
new Label("AirScout UDP port [9872] — reconnect after changing:");
Label lblASAutoBand =
new Label("Select AirScout frequency automatically per station:");
Label lblASBandName =
new Label("AirScout band value [1440000 = 144 MHz]:");
new Label("Forced AirScout band value [1440000 = 144 MHz]:");
CheckBox chkBxEnableUDPMsgbyAS = new CheckBox();
chkBxEnableUDPMsgbyAS.setSelected(
@@ -10092,13 +10111,38 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
chatcontroller.getChatPreferences()
.getAirScout_asBandString()
);
CheckBox chkBxAutoAirScoutBand = new CheckBox("Auto per station");
chkBxAutoAirScoutBand.setSelected(
chatcontroller.getChatPreferences()
.isAirScout_autoBandSelectionEnabled()
);
chkBxAutoAirScoutBand.setTooltip(
new Tooltip(
"Uses the station's current QRG first, then station-name and "
+ "chat-category evidence. Disable this option only to force "
+ "one protocol value for every station."
)
);
txtFld_asQRGInt.setDisable(chkBxAutoAirScoutBand.isSelected());
chkBxAutoAirScoutBand.selectedProperty().addListener(
(observable, oldValue, newValue) -> {
chatcontroller.getChatPreferences()
.setAirScout_autoBandSelectionEnabled(newValue);
txtFld_asQRGInt.setDisable(newValue);
}
);
txtFld_asQRGInt.setFocusTraversable(false);
txtFld_asQRGInt.setTooltip(
new Tooltip(
"AirScout protocol band value, for example 1440000 for "
+ "144 MHz or 4320000 for 432 MHz."
"Fallback used only when automatic per-station selection is "
+ "disabled. Examples: 1440000 for 144 MHz or 4320000 "
+ "for 432 MHz."
)
);
txtFld_asQRGInt.focusedProperty().addListener(
(observable, oldValue, newValue) -> {
if (newValue) {
@@ -10133,7 +10177,7 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
);
Label lblASChangeNote = new Label(
"Server identifier, client identifier and band are applied "
"Server identifier, client identifier and frequency mode are applied "
+ "immediately. Reconnect after changing the UDP port."
);
lblASChangeNote.setWrapText(true);
@@ -10156,9 +10200,11 @@ public class Kst4ContestApplication extends Application implements StatusUpdateL
grdPnlAirScout.add(txtFld_asClientNameString, 1, 3);
grdPnlAirScout.add(lblASUdpPort, 0, 4);
grdPnlAirScout.add(txtFld_asUDPPortInt, 1, 4);
grdPnlAirScout.add(lblASBandName, 0, 5);
grdPnlAirScout.add(txtFld_asQRGInt, 1, 5);
grdPnlAirScout.add(lblASChangeNote, 0, 6, 2, 1);
grdPnlAirScout.add(lblASAutoBand, 0, 5);
grdPnlAirScout.add(chkBxAutoAirScoutBand, 1, 5);
grdPnlAirScout.add(lblASBandName, 0, 6);
grdPnlAirScout.add(txtFld_asQRGInt, 1, 6);
grdPnlAirScout.add(lblASChangeNote, 0, 7, 2, 1);
VBox vbxAirScout = new VBox();
vbxAirScout.setPadding(new Insets(10, 10, 10, 10));
@@ -15,6 +15,7 @@ import java.util.LinkedHashMap;
import java.util.List;
import java.util.Locale;
import java.util.Map;
import kst4contest.logic.FrequencyTextParser;
/**
* Builds immutable map snapshots from the currently visible chat members.
@@ -204,6 +205,92 @@ public final class MapCallsignRawSnapshotBuilder {
));
}
}
}
/*
* A QRG explicitly contained in the current station name does not expire.
*
* Recent dynamic QRG evidence has priority. Therefore station-name QRGs fill
* only bands for which no recent dynamic frequency is available.
*
* Different explicit QRGs for the same band are considered ambiguous and are
* not reduced to one arbitrary run frequency.
*/
Map<Band, Map<String, FrequencyTextParser.DetectedFrequency>>
stationNameFrequenciesByBand =
new EnumMap<>(Band.class);
for (ChatMember variant : variants) {
if (variant == null) {
continue;
}
for (FrequencyTextParser.DetectedFrequency detectedFrequency
: FrequencyTextParser.findExplicitFrequencies(
variant.getName()
)) {
Band band =
detectedFrequency.getBand();
if (availableBands == null
|| !availableBands.contains(band)) {
continue;
}
stationNameFrequenciesByBand
.computeIfAbsent(
band,
ignored -> new LinkedHashMap<>()
)
.putIfAbsent(
Double.toString(
detectedFrequency.getFrequencyMHz()
),
detectedFrequency
);
}
}
for (Map.Entry<
Band,
Map<String, FrequencyTextParser.DetectedFrequency>>
entry : stationNameFrequenciesByBand.entrySet()) {
Band band = entry.getKey();
/*
* A recent QRG detected from chat always wins.
*/
if (latestByBand.containsKey(band)) {
continue;
}
/*
* Do not guess when several different QRGs were published for the
* same band.
*/
if (entry.getValue().size() != 1) {
continue;
}
FrequencyTextParser.DetectedFrequency detectedFrequency =
entry.getValue()
.values()
.iterator()
.next();
latestByBand.put(
band,
new FrequencyCandidate(
band,
formatFrequency(
detectedFrequency.getFrequencyMHz()
),
Long.MIN_VALUE
)
);
}
LinkedHashMap<String, String> ordered = new LinkedHashMap<>();
@@ -1,6 +1,5 @@
package kst4contest.view.map;
import java.util.Map;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
@@ -496,37 +495,7 @@ public final class PathGeometryUtils {
}
}
/**
* Resolves one usable analysis frequency from aggregated marker frequency data.
*
* <p>Strategy:
* <ol>
* <li>Prefer 144 MHz data if available</li>
* <li>Otherwise use the first parsable known station frequency</li>
* <li>Otherwise use the central default frequency</li>
* </ol>
*
* @param frequenciesByBand known frequencies grouped by band
* @return resolved analysis frequency in MHz
*/
public static double resolveAnalysisFrequencyMHz(Map<String, String> frequenciesByBand) {
if (frequenciesByBand != null && !frequenciesByBand.isEmpty()) {
String band144Text = frequenciesByBand.get("144");
double parsed144 = tryParseFrequencyMHz(band144Text);
if (Double.isFinite(parsed144) && parsed144 > 0.0) {
return parsed144;
}
for (String value : frequenciesByBand.values()) {
double parsedFrequencyMHz = tryParseFrequencyMHz(value);
if (Double.isFinite(parsedFrequencyMHz) && parsedFrequencyMHz > 0.0) {
return parsedFrequencyMHz;
}
}
}
return DEFAULT_ANALYSIS_FREQUENCY_MHZ;
}
/**
* Small immutable geographic point used by great-circle interpolation.
@@ -18,6 +18,7 @@ import java.util.Objects;
import java.util.concurrent.atomic.AtomicLong;
import java.util.function.Consumer;
import java.util.function.Supplier;
import kst4contest.model.Band;
import java.util.function.Predicate;
@@ -40,6 +41,7 @@ public final class StationMapBridge {
private final TableView<ChatMember> chatMemberTable;
private final StationMapView stationMapView;
private final Consumer<ChatMember> focusChatMemberConsumer;
private final Supplier<Band> reachabilityBandOverrideSupplier;
@@ -55,22 +57,30 @@ public final class StationMapBridge {
public StationMapBridge(ChatController chatController,
TableView<ChatMember> chatMemberTable,
StationMapView stationMapView,
Consumer<ChatMember> focusChatMemberConsumer) {
Consumer<ChatMember> focusChatMemberConsumer,
Supplier<Band> reachabilityBandOverrideSupplier) {
this.chatController = Objects.requireNonNull(chatController, "chatController");
this.chatMemberTable = Objects.requireNonNull(chatMemberTable, "chatMemberTable");
this.stationMapView = Objects.requireNonNull(stationMapView, "stationMapView");
this.focusChatMemberConsumer = Objects.requireNonNull(focusChatMemberConsumer, "focusChatMemberConsumer");
this.focusChatMemberConsumer = Objects.requireNonNull(
focusChatMemberConsumer,
"focusChatMemberConsumer"
);
this.reachabilityBandOverrideSupplier = Objects.requireNonNull(
reachabilityBandOverrideSupplier,
"reachabilityBandOverrideSupplier"
);
this.refreshCoalescer.setOnFinished(event -> refreshNow());
}
public void install() {
stationMapView.setOnCallsignRawSelected(this::handleMapCallsignSelection);
stationMapView.setOnTriggerClusterSpot(this::handleExplicitClusterSpot);
stationMapView.setOnResetView(this::handleMapReset);
chatController.getLst_chatMemberSortedFilteredList().addListener(
(ListChangeListener<ChatMember>) change -> scheduleRefresh()
);
@@ -90,6 +100,35 @@ public final class StationMapBridge {
requestImmediateRefresh();
}
private void handleMapReset() {
Runnable resetAction = () -> {
/*
* Ignore an analysis result that may still arrive for the
* previously selected station.
*/
pathAnalysisGeneration.incrementAndGet();
lastPathAnalysisRequestSignature = "";
/*
* Clear the application's central station selection.
*/
chatController.getScoreService().setSelectedChatMember(null);
/*
* Keep the main station table synchronized with the central selection.
*/
chatMemberTable.getSelectionModel().clearSelection();
requestImmediateRefresh();
};
if (Platform.isFxApplicationThread()) {
resetAction.run();
} else {
Platform.runLater(resetAction);
}
}
public void showWindow() {
stationMapView.showWindow();
requestImmediateRefresh();
@@ -115,6 +154,18 @@ public final class StationMapBridge {
}
}
/**
* Forces the currently selected map path to be requested again.
*
* <p>This is used by the explicit "Calc selected" action after the operator
* changed the reachability band. Merely changing the ComboBox still does not
* trigger terrain analysis.</p>
*/
public void requestSelectedPathAnalysisRefresh() {
lastPathAnalysisRequestSignature = "";
requestImmediateRefresh();
}
public void focusSelectedCallsign() {
showWindow();
@@ -222,9 +273,12 @@ public final class StationMapBridge {
ChatMember selectedMember = resolveBestChatMember(targetCallsignRaw);
Band requestedBandOverride = reachabilityBandOverrideSupplier.get();
chatController.getReachabilityService().requestPathAnalysisForMap(
selectedMember,
selectedSnapshot,
requestedBandOverride,
result -> {
if (generation != pathAnalysisGeneration.get()) {
return;
@@ -232,6 +286,7 @@ public final class StationMapBridge {
stationMapView.setPathAnalysisResult(result);
}
);
}
/**
@@ -259,6 +314,13 @@ public final class StationMapBridge {
chatMemberTable.scrollTo(resolved);
focusChatMemberConsumer.accept(resolved);
/*
* A map click is an explicit operator action. Clear the signature so a
* newly selected reachability band is honored even when the same station
* is clicked again.
*/
lastPathAnalysisRequestSignature = "";
requestImmediateRefresh();
});
}
@@ -315,10 +377,16 @@ public final class StationMapBridge {
private double resolveAnalysisFrequencyMHz(MapCallsignRawSnapshot selectedSnapshot) {
if (selectedSnapshot == null) {
return PathGeometryUtils.DEFAULT_ANALYSIS_FREQUENCY_MHZ;
return Double.NaN;
}
return PathGeometryUtils.resolveAnalysisFrequencyMHz(selectedSnapshot.lastKnownFrequenciesByBand());
ChatMember selectedMember = resolveBestChatMember(selectedSnapshot.callSignRaw());
var resolution = chatController.getReachabilityService()
.resolveAutomaticPropagationFrequency(selectedMember);
return resolution == null
? Double.NaN
: resolution.getAnalysisFrequencyMHz();
}
@@ -13,6 +13,7 @@ import javafx.scene.layout.VBox;
import javafx.scene.web.WebEngine;
import javafx.scene.web.WebView;
import javafx.stage.Stage;
import kst4contest.view.GuiUtils;
import netscape.javascript.JSObject;
import kst4contest.ApplicationConstants;
import kst4contest.locatorUtils.Location;
@@ -86,14 +87,15 @@ public final class StationMapView {
private final Button pathAnalysisVisibilityButton = new Button();
private final Tooltip pathAnalysisVisibilityTooltip = new Tooltip();
private final Button resetViewButton = new Button("Reset view");
private final Tooltip statusTooltip = new Tooltip();
private Runnable onResetView;
private double lastDetailDividerPosition = 0.65;
private final Label detailCallsignValue = new Label("-");
private final Label detailLocatorValue = new Label("-");
private final Label detailQrbValue = new Label("-");
private final Label detailQtfValue = new Label("-");
private final Label detailBandsValue = new Label("-");
private final TextArea detailFrequenciesArea = new TextArea();
private final Label detailAirplanesValue = new Label("-");
private final Button triggerClusterSpotButton = new Button("Trigger cluster spot");
private final Label detailPathFromLocatorValue = new Label("-");
@@ -179,6 +181,8 @@ public final class StationMapView {
public StationMapView(ChatPreferences chatPreferences) {
this.chatPreferences = Objects.requireNonNull(chatPreferences, "chatPreferences");
GuiUtils.applyApplicationIcon(stage);
try {
tileProxyServer = new TileProxyServer();
} catch (IOException e) {
@@ -207,6 +211,11 @@ public final class StationMapView {
this.onTriggerClusterSpot = onTriggerClusterSpot;
}
public void setOnResetView(Runnable onResetView) {
this.onResetView = onResetView;
}
public void showWindow() {
applyThemeFromPreferences();
@@ -279,10 +288,6 @@ public final class StationMapView {
stage.setTitle("Station Map");
detailFrequenciesArea.setEditable(false);
detailFrequenciesArea.setWrapText(true);
detailFrequenciesArea.setPrefRowCount(4);
detailPathEndpointsValue.setWrapText(true);
detailPathEndpointsValue.setMaxWidth(Double.MAX_VALUE);
@@ -296,12 +301,23 @@ public final class StationMapView {
detailPathMechanismsValue.setMaxWidth(Double.MAX_VALUE);
triggerClusterSpotButton.setDisable(true);
triggerClusterSpotButton.setVisible(false);
triggerClusterSpotButton.setManaged(false);
triggerClusterSpotButton.setMinWidth(Region.USE_PREF_SIZE);
triggerClusterSpotButton.setOnAction(event -> {
if (detailCallsignRaw != null && onTriggerClusterSpot != null) {
onTriggerClusterSpot.accept(detailCallsignRaw);
}
});
resetViewButton.setMinWidth(Region.USE_PREF_SIZE);
resetViewButton.setOnAction(event -> {
if (onResetView != null) {
onResetView.run();
}
});
pathAnalysisVisibilityButton.setMinWidth(Region.USE_PREF_SIZE);
pathAnalysisVisibilityButton.setTooltip(pathAnalysisVisibilityTooltip);
pathAnalysisVisibilityButton.setOnAction(event ->
@@ -374,7 +390,7 @@ public final class StationMapView {
);
pathAnalysisSection = createPathAnalysisSection();
detailPane = new VBox(10, createSelectedStationSection(), pathAnalysisSection);
detailPane = new VBox(10, pathAnalysisSection);
detailPane.setPadding(new Insets(10));
@@ -486,20 +502,25 @@ public final class StationMapView {
* must always have an obvious way to restore a previously hidden analysis.
*/
private HBox createMapHeader() {
// The status may be shortened before the show/hide control is ever clipped.
statusLabel.setMinWidth(0);
statusLabel.setMaxWidth(Double.MAX_VALUE);
statusLabel.setTextOverrun(OverrunStyle.ELLIPSIS);
statusLabel.setTooltip(statusTooltip);
HBox header = new HBox(
10,
statusLabel,
triggerClusterSpotButton,
resetViewButton,
pathAnalysisHiddenHintLabel,
pathAnalysisVisibilityButton
);
header.setAlignment(Pos.CENTER_LEFT);
header.setPadding(new Insets(8));
HBox.setHgrow(statusLabel, Priority.ALWAYS);
return header;
}
@@ -520,6 +541,7 @@ public final class StationMapView {
pathAnalysisSection.setVisible(visible);
pathAnalysisSection.setManaged(visible);
updateDetailPanePresence(visible);
pathAnalysisHiddenHintLabel.setVisible(!visible);
pathAnalysisHiddenHintLabel.setManaged(!visible);
@@ -564,45 +586,6 @@ public final class StationMapView {
: MINIMUM_HEIGHT_WITHOUT_PATH_ANALYSIS;
}
private VBox createSelectedStationSection() {
GridPane detailGrid = new GridPane();
detailGrid.setHgap(8);
detailGrid.setVgap(6);
configureCompactGrid(detailGrid);
int row = 0;
detailGrid.add(new Label("Station:"), 0, row);
detailGrid.add(detailCallsignValue, 1, row++);
detailGrid.add(new Label("Locator:"), 0, row);
detailGrid.add(detailLocatorValue, 1, row++);
detailGrid.add(new Label("Path:"), 0, row);
Label compactPathValue = new Label();
compactPathValue.textProperty().bind(
detailQrbValue.textProperty()
.concat(" / ")
.concat(detailQtfValue.textProperty())
);
detailGrid.add(compactPathValue, 1, row++);
detailGrid.add(new Label("Bands:"), 0, row);
detailGrid.add(detailBandsValue, 1, row++);
// Frequencies are useful, but they consume vertical space. Keep them compact.
detailFrequenciesArea.setPrefRowCount(2);
detailGrid.add(new Label("QRG:"), 0, row);
detailGrid.add(detailFrequenciesArea, 1, row++);
return new VBox(8,
new Label("Selected station"),
new Separator(Orientation.HORIZONTAL),
detailGrid,
triggerClusterSpotButton
);
}
/**
* ensures that the labels remains visible
@@ -947,58 +930,107 @@ public final class StationMapView {
private void updateStatusLabel() {
StringBuilder text = new StringBuilder();
text.append("Showing ").append(lastSnapshots.size()).append(" visible stations");
text.append("Showing ")
.append(lastSnapshots.size())
.append(" visible stations");
if (filteredViewActive) {
text.append(" | filtered view active");
}
statusLabel.setText(text.toString());
MapCallsignRawSnapshot selectedSnapshot = lastSelectedSnapshot;
if (selectedSnapshot != null) {
text.append(" | Selected: ")
.append(selectedSnapshot.displayCallSign());
if (!selectedSnapshot.locator6().isBlank()) {
text.append(" | ")
.append(selectedSnapshot.locator6());
}
text.append(" | ")
.append(String.format(
Locale.US,
"%.0f km / %.0f°",
selectedSnapshot.qrbKm(),
selectedSnapshot.qtfDeg()
));
String bandText = selectedSnapshot.bandSummary().isBlank()
? "-"
: selectedSnapshot.bandSummary();
if (selectedSnapshot.offersSelectedBand()) {
bandText += " B+";
}
text.append(" | Bands: ")
.append(bandText);
String frequencies = selectedSnapshot.detailFrequencyText();
if (frequencies != null && !frequencies.isBlank()) {
frequencies = frequencies
.replace('\n', ' ')
.replace('\r', ' ')
.replaceAll("\\s+", " ")
.trim();
text.append(" | QRG: ")
.append(frequencies);
}
}
String statusText = text.toString();
statusLabel.setText(statusText);
statusTooltip.setText(statusText);
}
private void updateDetailPanel(MapCallsignRawSnapshot selectedSnapshot) {
if (selectedSnapshot == null) {
clearSelectedStationPanel();
detailCallsignRaw = null;
triggerClusterSpotButton.setDisable(true);
triggerClusterSpotButton.setVisible(false);
triggerClusterSpotButton.setManaged(false);
clearPathAnalysisPanel();
return;
}
updateSelectedStationPanel(selectedSnapshot);
if (selectedSnapshot == null) {
updatePathAnalysisPanel(PathAnalysisResult.waitingForSelection(homeLocator6));
} else {
updatePathAnalysisPanel(lastPathAnalysisResult);
}
}
private void clearSelectedStationPanel() {
detailCallsignRaw = null;
detailCallsignValue.setText("-");
detailLocatorValue.setText("-");
detailQrbValue.setText("-");
detailQtfValue.setText("-");
detailBandsValue.setText("-");
detailFrequenciesArea.setText("-");
detailAirplanesValue.setText("-");
triggerClusterSpotButton.setDisable(true);
}
private void updateSelectedStationPanel(MapCallsignRawSnapshot selectedSnapshot) {
detailCallsignRaw = selectedSnapshot.callSignRaw();
detailCallsignValue.setText(selectedSnapshot.displayCallSign());
detailLocatorValue.setText(selectedSnapshot.locator6());
detailQrbValue.setText(String.format(Locale.US, "%.0f km", selectedSnapshot.qrbKm()));
detailQtfValue.setText(String.format(Locale.US, "%.0f°", selectedSnapshot.qtfDeg()));
String bandText = selectedSnapshot.bandSummary().isBlank() ? "-" : selectedSnapshot.bandSummary();
if (selectedSnapshot.offersSelectedBand()) {
bandText += " B+";
}
detailBandsValue.setText(bandText);
detailFrequenciesArea.setText(selectedSnapshot.detailFrequencyText());
detailAirplanesValue.setText(String.valueOf(selectedSnapshot.reachableAirplanes()));
triggerClusterSpotButton.setDisable(false);
triggerClusterSpotButton.setVisible(true);
triggerClusterSpotButton.setManaged(true);
updatePathAnalysisPanel(lastPathAnalysisResult);
}
private void updateDetailPanePresence(boolean visible) {
if (mainSplitPane == null || detailScrollPane == null) {
return;
}
if (visible) {
if (!mainSplitPane.getItems().contains(detailScrollPane)) {
mainSplitPane.getItems().add(detailScrollPane);
Platform.runLater(() ->
mainSplitPane.setDividerPositions(lastDetailDividerPosition)
);
}
} else {
if (!mainSplitPane.getDividers().isEmpty()) {
lastDetailDividerPosition =
mainSplitPane.getDividers().get(0).getPosition();
}
mainSplitPane.getItems().remove(detailScrollPane);
}
}
private void clearPathAnalysisPanel() {
@@ -1328,13 +1360,13 @@ public final class StationMapView {
mainSplitPane.setStyle("-fx-background-color: #2b3035;");
detailPane.setStyle("-fx-background-color: #31373c; -fx-border-color: #4c565c; -fx-border-width: 0 0 0 1;");
statusLabel.setStyle("-fx-background-color: #373e43; -fx-text-fill: lightgray; -fx-padding: 8 10 8 10; -fx-background-radius: 4;");
detailFrequenciesArea.setStyle("-fx-control-inner-background: #444b50; -fx-text-fill: lightgray;");
// detailFrequenciesArea.setStyle("-fx-control-inner-background: #444b50; -fx-text-fill: lightgray;");
} else {
rootPane.setStyle("-fx-background-color: #f2f2f2;");
mainSplitPane.setStyle("-fx-background-color: #f2f2f2;");
detailPane.setStyle("-fx-background-color: #f7f7f7; -fx-border-color: #d0d0d0; -fx-border-width: 0 0 0 1;");
statusLabel.setStyle("-fx-background-color: #f7f7f7; -fx-text-fill: #333333; -fx-padding: 8 10 8 10; -fx-background-radius: 4;");
detailFrequenciesArea.setStyle("");
// detailFrequenciesArea.setStyle("");
}
}
Binary file not shown.
Binary file not shown.

After

Width:  |  Height:  |  Size: 264 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.9 KiB

@@ -14,6 +14,39 @@ import static org.junit.jupiter.api.Assertions.assertTrue;
class BandOpportunityResolverTest {
@Test
void explicitStationNameFrequencyProvidesBandEvidence() {
ChatMember station = new ChatMember();
station.setName("Phil 432.357");
BandOpportunityResolver.Resolution resolution =
BandOpportunityResolver.resolve(
List.of(station),
System.currentTimeMillis()
);
assertEquals(
EnumSet.of(Band.B_432),
resolution.getOfferedBands()
);
}
@Test
void relativeStationNameFrequencyDoesNotProvideBandEvidence() {
ChatMember station = new ChatMember();
station.setName("Mike .180");
BandOpportunityResolver.Resolution resolution =
BandOpportunityResolver.resolve(
List.of(station),
System.currentTimeMillis()
);
assertTrue(
resolution.getOfferedBands().isEmpty()
);
}
@Test
void resolvesCommonShorthandBandsFromStationName() {
EnumSet<Band> bands = BandOpportunityResolver.detectBandsFromStationName(
@@ -15,6 +15,70 @@ import static org.junit.jupiter.api.Assertions.assertTrue;
class MapCallsignRawSnapshotBuilderTest {
@Test
void explicitStationNameQrgIsShownInMapSnapshot() {
ChatMember station =
buildStation(
"G0JSB",
"Phil 432.357",
"IO91AA",
1_000L
);
MapCallsignRawSnapshot snapshot =
new MapCallsignRawSnapshotBuilder()
.buildSnapshots(
List.of(station),
null,
EnumSet.of(Band.B_432)
)
.get(0);
assertEquals(
"432",
snapshot.bandSummary()
);
assertEquals(
"432.357",
snapshot
.lastKnownFrequenciesByBand()
.get("432")
);
}
@Test
void recentDynamicQrgWinsOverStationNameQrgInMap() {
ChatMember station =
buildStation(
"G0JSB",
"Phil 432.357",
"IO91AA",
1_000L
);
station.addKnownFrequency(
Band.B_432,
432.335
);
MapCallsignRawSnapshot snapshot =
new MapCallsignRawSnapshotBuilder()
.buildSnapshots(
List.of(station),
null,
EnumSet.of(Band.B_432)
)
.get(0);
assertEquals(
"432.335",
snapshot
.lastKnownFrequenciesByBand()
.get("432")
);
}
@Test
void marksSnapshotWhenNameAdvertisesSelectedBand() {
ChatMember station = buildStation("DL1ABC", "QRV 2-70-23", "JN58TD", 1_000L);
@@ -0,0 +1,291 @@
package kst4contest.test;
import kst4contest.logic.PropagationFrequencyResolver;
import kst4contest.model.Band;
import kst4contest.model.ChatCategory;
import kst4contest.model.ChatMember;
import org.junit.jupiter.api.Test;
import java.util.EnumSet;
import java.util.List;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertNull;
class PropagationFrequencyResolverTest {
private static final long NOW = 10_000_000L;
@Test
void exactStationNameQrgWinsOverBandAndCategoryFallback() {
ChatMember station =
station(
ChatCategory.VUHF,
"Phil 432.357"
);
PropagationFrequencyResolver.Resolution resolution =
resolve(
List.of(station),
EnumSet.of(
Band.B_144,
Band.B_432
)
);
assertEquals(
Band.B_432,
resolution.getBand()
);
assertEquals(
432.357,
resolution.getAnalysisFrequencyMHz(),
0.000_001
);
assertEquals(
PropagationFrequencyResolver.Source.STATION_NAME_QRG,
resolution.getSource()
);
}
@Test
void recentChatQrgWinsOverExactStationNameQrg() {
ChatMember station =
station(
ChatCategory.VUHF,
"Phil 432.357"
);
addCurrentQrg(
station,
Band.B_432,
432.335,
NOW - 1_000L
);
PropagationFrequencyResolver.Resolution resolution =
resolve(
List.of(station),
EnumSet.of(Band.B_432)
);
assertEquals(
432.335,
resolution.getAnalysisFrequencyMHz(),
0.000_001
);
assertEquals(
PropagationFrequencyResolver.Source.CURRENT_QRG,
resolution.getSource()
);
}
@Test
void multipleStationNameQrgsAreNotTreatedAsOneRunFrequency() {
ChatMember station =
station(
ChatCategory.EMEJT65,
"QRV 432.357 1296.210"
);
PropagationFrequencyResolver.Resolution resolution =
resolve(
List.of(station),
EnumSet.of(
Band.B_432,
Band.B_1296
)
);
/*
* Both bands are known, but no exact run QRG is guessed.
* Existing station-name band selection therefore chooses the
* lowest usable advertised band.
*/
assertEquals(
Band.B_432,
resolution.getBand()
);
assertEquals(
432.0,
resolution.getAnalysisFrequencyMHz(),
0.000_001
);
assertEquals(
PropagationFrequencyResolver.Source.STATION_NAME,
resolution.getSource()
);
}
@Test
void currentQrgWinsOverNameAndCategoryFallback() {
ChatMember station = station(ChatCategory.MICROWAVE, "QRV 3cm");
addCurrentQrg(station, Band.B_2320, 2320.175, NOW - 1_000L);
PropagationFrequencyResolver.Resolution resolution = resolve(
List.of(station),
EnumSet.of(Band.B_1296, Band.B_2320, Band.B_10G)
);
assertEquals(Band.B_2320, resolution.getBand());
assertEquals(2320.175, resolution.getAnalysisFrequencyMHz(), 0.000_001);
assertEquals(PropagationFrequencyResolver.Source.CURRENT_QRG, resolution.getSource());
assertEquals("23201750", resolution.getAirScoutBandValue());
}
@Test
void mostRecentlyDetectedQrgWinsAcrossCategoryVariants() {
ChatMember vhf = station(ChatCategory.VUHF, "");
ChatMember microwave = station(ChatCategory.MICROWAVE, "");
addCurrentQrg(vhf, Band.B_144, 144.210, NOW - 10_000L);
addCurrentQrg(microwave, Band.B_1296, 1296.210, NOW - 1_000L);
PropagationFrequencyResolver.Resolution resolution = resolve(
List.of(vhf, microwave),
EnumSet.of(Band.B_144, Band.B_432, Band.B_1296)
);
assertEquals(Band.B_1296, resolution.getBand());
assertEquals(1296.210, resolution.getAnalysisFrequencyMHz(), 0.000_001);
}
@Test
void microwaveFallsBackToLowestEnabledMicrowaveBand() {
ChatMember station = station(ChatCategory.MICROWAVE, "");
PropagationFrequencyResolver.Resolution resolution = resolve(
List.of(station),
EnumSet.of(Band.B_2320, Band.B_3400)
);
assertEquals(Band.B_2320, resolution.getBand());
assertEquals(2320.0, resolution.getAnalysisFrequencyMHz(), 0.000_001);
assertEquals(PropagationFrequencyResolver.Source.CHAT_CATEGORY, resolution.getSource());
}
@Test
void supportedCategoriesUseTheirAgreedLowestFallbackBand() {
assertEquals(
Band.B_50,
resolve(
List.of(station(ChatCategory.FIFTYSEVENTYMHz, "")),
EnumSet.of(Band.B_50, Band.B_70)
).getBand()
);
assertEquals(
Band.B_144,
resolve(
List.of(station(ChatCategory.VUHF, "")),
EnumSet.of(Band.B_144, Band.B_432)
).getBand()
);
assertEquals(
Band.B_1296,
resolve(
List.of(station(ChatCategory.MICROWAVE, "")),
EnumSet.of(Band.B_1296, Band.B_2320)
).getBand()
);
assertEquals(
Band.B_144,
resolve(
List.of(station(ChatCategory.EMEJT65, "")),
EnumSet.of(Band.B_144, Band.B_1296)
).getBand()
);
}
@Test
void vhfAndMicrowaveUse432MhzFallback() {
ChatMember vhf = station(ChatCategory.VUHF, "");
ChatMember microwave = station(ChatCategory.MICROWAVE, "");
PropagationFrequencyResolver.Resolution resolution = resolve(
List.of(vhf, microwave),
EnumSet.of(Band.B_144, Band.B_432, Band.B_1296)
);
assertEquals(Band.B_432, resolution.getBand());
assertEquals(432.0, resolution.getAnalysisFrequencyMHz(), 0.000_001);
assertEquals(
PropagationFrequencyResolver.Source.DUAL_CATEGORY_FALLBACK,
resolution.getSource()
);
assertEquals("4320000", resolution.getAirScoutBandValue());
}
@Test
void unsupportedChatCategoriesDoNotFallBackTo144Mhz() {
for (int categoryNumber = ChatCategory.LOWBAND;
categoryNumber <= ChatCategory.TENMeter;
categoryNumber++) {
ChatMember unsupported = station(categoryNumber, "QRV 2m");
addCurrentQrg(unsupported, Band.B_144, 144.300, NOW - 1_000L);
assertNull(
resolve(
List.of(unsupported),
EnumSet.of(Band.B_144, Band.B_432)
),
"Category " + categoryNumber + " must be ignored"
);
}
}
@Test
void manualNotQrvExclusionForcesNextUsableMicrowaveBand() {
ChatMember station = station(ChatCategory.MICROWAVE, "");
station.setQrv1240(false);
PropagationFrequencyResolver.Resolution resolution = resolve(
List.of(station),
EnumSet.of(Band.B_1296, Band.B_2320)
);
assertEquals(Band.B_2320, resolution.getBand());
assertEquals(2320.0, resolution.getAnalysisFrequencyMHz(), 0.000_001);
}
@Test
void stationNameBandHintWinsOverCategoryFallback() {
ChatMember station = station(ChatCategory.MICROWAVE, "QRV 3cm");
PropagationFrequencyResolver.Resolution resolution = resolve(
List.of(station),
EnumSet.of(Band.B_1296, Band.B_10G)
);
assertEquals(Band.B_10G, resolution.getBand());
assertEquals(10368.0, resolution.getAnalysisFrequencyMHz(), 0.000_001);
assertEquals(PropagationFrequencyResolver.Source.STATION_NAME, resolution.getSource());
}
private PropagationFrequencyResolver.Resolution resolve(
List<ChatMember> variants,
EnumSet<Band> enabledBands
) {
return PropagationFrequencyResolver.resolve(variants, enabledBands, NOW);
}
private ChatMember station(int categoryNumber, String name) {
ChatMember station = new ChatMember();
station.setCallSign("DL1ABC");
station.setChatCategory(new ChatCategory(categoryNumber));
station.setName(name);
return station;
}
private void addCurrentQrg(ChatMember station,
Band band,
double frequencyMHz,
long timestampEpochMs) {
station.addKnownFrequency(band, frequencyMHz);
station.getKnownActiveBands().get(band).timestampEpoch = timestampEpochMs;
}
}
+5 -1
View File
@@ -2382,4 +2382,8 @@ OV3T;Thomas;JO46CM;StringProperty [value: null]; wkd true; wkd144 true; wkd432fa
OZ6TY;Henning;JO55XE;StringProperty [value: 144.196]; wkd true; wkd144 true; wkd432false; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
DF7KF;Dithmar;JO30FK;StringProperty [value: null]; wkd true; wkd144 true; wkd432false; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
DH1NFJ;Jochen;JO50QL;StringProperty [value: null]; wkd true; wkd144 false; wkd432true; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 3: Microwave
PA2RU;René;JO32LT;StringProperty [value: null]; wkd true; wkd144 false; wkd432false; wkd1240true; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
PA2RU;René;JO32LT;StringProperty [value: null]; wkd true; wkd144 false; wkd432false; wkd1240true; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
SM6VTZ;Chris .135;JO58UJ;StringProperty [value: 144.135]; wkd true; wkd144 false; wkd432true; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
SM7EYW;Torleif 432,205;JO65NK;StringProperty [value: 144.205]; wkd true; wkd144 false; wkd432true; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
DJ8MS;Tor_70cm;JO54UC;StringProperty [value: null]; wkd true; wkd144 false; wkd432true; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
DK0MM;Jens/Alex;JN49IU;StringProperty [value: 432.305]; wkd true; wkd144 false; wkd432true; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
+3 -1
View File
@@ -4,7 +4,9 @@
"private": true,
"scripts": {
"start": "eleventy --serve",
"build": "eleventy"
"build": "eleventy && npm run validate:version-info",
"validate:version-info": "node scripts/validate-version-info.js",
"test": "node --test test/*.test.js"
},
"devDependencies": {
"@11ty/eleventy": "^3.0.0"
+280
View File
@@ -0,0 +1,280 @@
const fs = require("fs");
const path = require("path");
const DEFAULT_FILE = path.join(
__dirname,
"..",
"_site",
"kst4ContestVersionInfo.xml"
);
function fail(message) {
throw new Error(`[versionInfo validation] ${message}`);
}
function normaliseVersion(value) {
return String(value || "")
.trim()
.replace(/^v/, "")
.split("-")[0]
.split("+")[0];
}
function extractTag(xml, tagName) {
const match = xml.match(
new RegExp(`<${tagName}>([\\s\\S]*?)<\\/${tagName}>`)
);
return match ? match[1].trim() : null;
}
function assertWellFormedStructure(xml) {
if (/&(?!amp;|lt;|gt;|quot;|apos;|#\d+;|#x[0-9a-f]+;)/i.test(xml)) {
fail("the XML contains an unescaped ampersand");
}
const withoutCommentsAndDeclaration = xml
.replace(/<!--[\s\S]*?-->/g, "")
.replace(/<\?[\s\S]*?\?>/g, "");
const tagPattern =
/<\/?([A-Za-z_][\w:.-]*)(?:\s[^<>]*?)?\s*\/?>/g;
const stack = [];
let match;
while (
(match = tagPattern.exec(withoutCommentsAndDeclaration)) !== null
) {
const fullTag = match[0];
const tagName = match[1];
if (fullTag.startsWith("</")) {
const openTag = stack.pop();
if (openTag !== tagName) {
fail(
`closing tag </${tagName}> does not match `
+ `<${openTag || "none"}>`
);
}
} else if (!fullTag.endsWith("/>")) {
stack.push(tagName);
}
}
if (stack.length > 0) {
fail(`unclosed tag <${stack[stack.length - 1]}>`);
}
const remainingMarkup =
withoutCommentsAndDeclaration.replace(tagPattern, "");
// A plain ">" is legal character data and occurs in historical
// changelog notation such as "->". A remaining "<" cannot be legal
// after all valid tags have been removed.
if (/</.test(remainingMarkup)) {
fail("the XML contains malformed markup");
}
}
function assertContainsTag(block, tagName) {
const pattern =
new RegExp(`<${tagName}>[\\s\\S]*?<\\/${tagName}>`);
if (!pattern.test(block)) {
fail(`required element <${tagName}> is missing`);
}
}
function validateVersionInfo(xml, expectedStableVersion = "") {
if (!xml || Buffer.byteLength(xml, "utf8") < 500) {
fail("the generated file is empty or implausibly small");
}
assertWellFormedStructure(xml);
const completeDocumentPattern =
/^<\?xml[^>]*>\s*<praktiKST>[\s\S]*<\/praktiKST>\s*$/;
if (!completeDocumentPattern.test(xml)) {
fail(
"the document does not contain one complete "
+ "<praktiKST> root element"
);
}
const latestVersionBlock = extractTag(xml, "latestVersion");
if (latestVersionBlock === null) {
fail("<latestVersion> is missing");
}
for (const tagName of [
"versionNumber",
"semanticVersion",
"adminMessage",
"majorChanges",
"latestVersionPathOnWebserver"
]) {
assertContainsTag(latestVersionBlock, tagName);
}
const legacyVersion =
extractTag(latestVersionBlock, "versionNumber");
const semanticVersion =
extractTag(latestVersionBlock, "semanticVersion");
const releaseUrl =
extractTag(
latestVersionBlock,
"latestVersionPathOnWebserver"
);
if (
!legacyVersion
|| !/^\d+(?:\.\d+)?$/.test(legacyVersion)
) {
fail(
"<versionNumber> is not a valid legacy numeric version"
);
}
if (
!semanticVersion
|| !/^\d+\.\d+(?:\.\d+)?$/.test(semanticVersion)
) {
fail("<semanticVersion> is not a valid Stable version");
}
if (
!releaseUrl
|| !releaseUrl.startsWith(
"https://github.com/praktimarc/"
+ "kst4contest/releases/tag/"
)
) {
fail(
"<latestVersionPathOnWebserver> is not "
+ "a KST4Contest release URL"
);
}
const changeLogs = [
...xml.matchAll(
/<changeLog>([\s\S]*?)<\/changeLog>/g
)
].map((match) => match[1]);
if (changeLogs.length === 0) {
fail(
"the document does not contain any "
+ "<changeLog> entries"
);
}
for (const entry of changeLogs) {
for (const tagName of [
"changedVersionNumber",
"date",
"description",
"added",
"changed",
"fixed",
"removed"
]) {
assertContainsTag(entry, tagName);
}
}
const expected = normaliseVersion(expectedStableVersion);
if (expected) {
if (semanticVersion !== expected) {
fail(
`latest Stable version ${semanticVersion} `
+ `does not match expected release ${expected}`
);
}
const releaseEntryExists = changeLogs.some(
(entry) =>
extractTag(
entry,
"changedVersionNumber"
) === expected
);
if (!releaseEntryExists) {
fail(
"the changelog does not contain the expected "
+ `Stable release ${expected}`
);
}
}
return {
semanticVersion,
changeLogEntries: changeLogs.length
};
}
function parseArguments(argv) {
const result = {
file: DEFAULT_FILE,
expectedStableVersion:
process.env.EXPECTED_STABLE_VERSION || ""
};
for (let index = 0; index < argv.length; index++) {
if (
argv[index] === "--file"
&& argv[index + 1]
) {
result.file = path.resolve(argv[++index]);
} else if (
argv[index] === "--expected-stable"
&& argv[index + 1]
) {
result.expectedStableVersion = argv[++index];
} else {
fail(
`unknown or incomplete argument: ${argv[index]}`
);
}
}
return result;
}
if (require.main === module) {
try {
const options =
parseArguments(process.argv.slice(2));
const xml =
fs.readFileSync(options.file, "utf8");
const result =
validateVersionInfo(
xml,
options.expectedStableVersion
);
console.log(
`[versionInfo validation] OK: `
+ `Stable ${result.semanticVersion}, `
+ `${result.changeLogEntries} changelog entries, `
+ options.file
);
} catch (err) {
console.error(err.message);
process.exitCode = 1;
}
}
module.exports = {
normaliseVersion,
validateVersionInfo
};
+143 -20
View File
@@ -5,16 +5,93 @@ const REPO = "praktimarc/kst4contest";
const API = `https://api.github.com/repos/${REPO}`;
const LABEL_MAP = { enhancement: "added", bug: "fixed" };
const GITHUB_API_ATTEMPTS = 3;
function wait(milliseconds) {
return new Promise(
(resolve) => setTimeout(resolve, milliseconds)
);
}
async function githubGet(urlPath) {
const headers = { Accept: "application/vnd.github+json" };
const headers = {
Accept: "application/vnd.github+json"
};
if (process.env.GITHUB_TOKEN) {
headers.Authorization = `Bearer ${process.env.GITHUB_TOKEN}`;
headers.Authorization =
`Bearer ${process.env.GITHUB_TOKEN}`;
}
const res = await fetch(`${API}${urlPath}`, { headers });
if (!res.ok) {
throw new Error(`GitHub API ${urlPath} failed: ${res.status}`);
let lastError = null;
for (
let attempt = 1;
attempt <= GITHUB_API_ATTEMPTS;
attempt++
) {
try {
const res = await fetch(
`${API}${urlPath}`,
{
headers,
signal: AbortSignal.timeout(15000)
}
);
if (res.ok) {
return res.json();
}
const rateLimitRemaining =
res.headers.get("x-ratelimit-remaining");
const rateLimitReset =
res.headers.get("x-ratelimit-reset");
const rateLimitInfo =
rateLimitRemaining === null
? ""
: `, rate limit remaining `
+ rateLimitRemaining
+ (
rateLimitReset
? `, reset ${rateLimitReset}`
: ""
);
lastError = new Error(
`GitHub API ${urlPath} failed with `
+ `HTTP ${res.status}${rateLimitInfo}`
);
// Authentication and permission errors do not
// become valid by retrying.
if (
![408, 429].includes(res.status)
&& res.status < 500
) {
throw lastError;
}
} catch (err) {
lastError = err;
// Do not hide an invalid or expired token behind
// repeated requests.
if (
/HTTP (401|403|404)/.test(err.message)
) {
throw err;
}
}
if (attempt < GITHUB_API_ATTEMPTS) {
await wait(attempt * 500);
}
}
return res.json();
throw lastError
|| new Error(`GitHub API ${urlPath} failed`);
}
// UpdateChecker.java parses <versionNumber> with Double.parseDouble() and
@@ -108,25 +185,64 @@ function loadLegacySections() {
// UpdateChecker.java) from GitHub releases + closed issues, falling back to
// version-history.xml for releases that predate GitHub Releases.
module.exports = async function () {
const fallback = '<?xml version="1.0" encoding="UTF-8" standalone="no"?>\n<praktiKST></praktiKST>';
try {
const historyEntries = loadHistoryEntries();
const rawReleases = await githubGet("/releases?per_page=100");
const rawReleases =
await githubGet("/releases?per_page=100");
if (!Array.isArray(rawReleases)) {
throw new Error(
"GitHub releases response was not an array"
);
}
const releases = rawReleases
.map((r) => ({
tagName: r.tag_name,
publishedAt: r.published_at || "",
name: r.name || r.tag_name,
body: r.body || "",
isPrerelease: r.prerelease
.map((release) => ({
tagName: release.tag_name,
publishedAt: release.published_at || "",
name:
release.name
|| release.tag_name,
body: release.body || "",
isPrerelease: release.prerelease,
isDraft: release.draft
}))
.sort((a, b) => (a.publishedAt < b.publishedAt ? 1 : -1));
.sort(
(first, second) =>
first.publishedAt
< second.publishedAt
? 1
: -1
);
const stableReleases = releases.filter(
(release) =>
!release.isPrerelease
&& !release.isDraft
);
const stableReleases = releases.filter((r) => !r.isPrerelease);
const stable = stableReleases[0];
const ghVersions = new Set(stableReleases.map((r) => toAppVersionNumber(r.tagName)));
if (
!stable
|| !stable.tagName
|| !stable.publishedAt
) {
throw new Error(
"GitHub did not return "
+ "a published Stable release"
);
}
const ghVersions = new Set(
stableReleases.map(
(release) =>
toAppVersionNumber(
release.tagName
)
)
);
const parts = [];
parts.push('<?xml version="1.0" encoding="UTF-8" standalone="no"?>');
@@ -203,7 +319,14 @@ module.exports = async function () {
parts.push("</praktiKST>");
return parts.join("\n");
} catch (err) {
console.warn(`[versionInfo] Could not generate version info XML, using empty fallback: ${err.message}`);
return fallback;
throw new Error(
"[versionInfo] Could not generate "
+ "a complete update feed. "
+ "The website build has been aborted "
+ "so that the existing production feed "
+ "remains untouched: "
+ err.message,
{ cause: err }
);
}
};
+4 -2
View File
@@ -1,10 +1,12 @@
<!doctype html>
<html lang="en">
<html lang="{{ lang or 'en' }}">
<head>
<meta charset="utf-8">
<title>{{ title or "KST4Contest" }}</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="theme-color" content="#08110b">
<link rel="icon" href="/assets/favicon.svg" type="image/svg+xml">
<link rel="icon" href="/assets/favicon.svg" type="image/svg+xml">
<meta name="description" content="{{ description or 'KST4Contest connects ON4KST chat, candidate selection, sked planning and station software for VHF, UHF and SHF contest operation.' }}">
<link rel="canonical" href="https://kst4contest.hamradioonline.de{{ page.url }}">
@@ -13,7 +15,7 @@
<meta property="og:description" content="{{ description or 'ON4KST chat, candidate selection, sked planning and station software in one VHF, UHF and SHF contest workflow.' }}">
<meta property="og:url" content="https://kst4contest.hamradioonline.de{{ page.url }}">
<meta property="og:site_name" content="KST4Contest">
<meta property="og:locale" content="en_GB">
<meta property="og:locale" content="{{ 'de_DE' if lang == 'de' else 'en_GB' }}">
<meta property="og:image" content="https://kst4contest.hamradioonline.de/assets/social/kst4contest-og.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
+37 -19
View File
@@ -1,40 +1,44 @@
---
layout: base.njk
lang: en
---
<section class="hero">
<p class="badge">{{ category }} · since {{ since }}</p>
<p class="eyebrow">{{ category }} · available since {{ since }}</p>
<h1>{{ title }}</h1>
<p class="lead">{{ summary }}</p>
<div class="actions">
<a class="button secondary" href="/features/">← All functions</a>
<a class="button ghost" href="/manual/en/">Open the manual</a>
</div>
</section>
<section class="section narrow">
<article class="card content-card">
<div class="feature-icon large">{{ icon }}</div>
<div class="feature-icon large" aria-hidden="true">{{ icon }}</div>
{{ content | safe }}
{% if tagsList %}
<h2>Keywords</h2>
<div class="tag-list">
{% for tag in tagsList %}
<span>{{ tag }}</span>
{% endfor %}
</div>
{% endif %}
{% if related %}
<h2>Related features</h2>
<h2>Related functions</h2>
<div class="actions">
{% for slug in related %}
{% for item in collections.sortedFeatures %}
{% if item.fileSlug == slug %}
<a class="button secondary" href="{{ item.url }}">{{ item.data.title }}</a>
<a class="button secondary" href="{{ item.url }}">
{{ item.data.title }}
</a>
{% endif %}
{% endfor %}
{% endfor %}
</div>
{% endif %}
<p>
<a href="/features/">← Back to all functions</a>
</p>
</article>
</section>
@@ -44,15 +48,29 @@ layout: base.njk
"@type": "TechArticle",
"headline": "{{ title }}",
"description": "{{ summary }}",
"about": "KST4Contest",
"url": "https://kst4contest.hamradioonline.de{{ page.url }}",
"author": {
"@type": "Person",
"name": "Praktimarc"
{% if tagsList %}
"keywords": "{{ tagsList | join(', ') }}",
{% endif %}
"about": {
"@type": "SoftwareApplication",
"name": "KST4Contest",
"url": "https://kst4contest.hamradioonline.de/"
},
"url": "https://kst4contest.hamradioonline.de{{ page.url }}",
"author": [
{
"@type": "Person",
"name": "Marc Fröhlich (DO5AMF)"
},
{
"@type": "Person",
"name": "Philipp (DN9APW)"
}
],
"publisher": {
"@type": "Organization",
"name": "KST4Contest"
"name": "KST4Contest Project",
"url": "https://kst4contest.hamradioonline.de/"
}
}
</script>
+89
View File
@@ -0,0 +1,89 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
viewBox="0 0 48 48"
width="48"
height="48"
role="img"
version="1.1"
id="svg5"
sodipodi:docname="_raw_06-favicon.svg"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns="http://www.w3.org/2000/svg"
xmlns:svg="http://www.w3.org/2000/svg">
<defs
id="defs5" />
<sodipodi:namedview
id="namedview5"
pagecolor="#ffffff"
bordercolor="#000000"
borderopacity="0.25"
inkscape:showpageshadow="2"
inkscape:pageopacity="0.0"
inkscape:pagecheckerboard="0"
inkscape:deskcolor="#d1d1d1" />
<title
id="title1">KST4Contest Favicon — Dark</title>
<rect
x="2"
y="2"
width="44"
height="44"
rx="10"
fill="#5FD63A"
id="rect1" />
<g
transform="translate(12.3 9.4) scale(0.325)"
id="g5">
<g
fill="none"
stroke="#0F150F"
stroke-width="4.2"
stroke-linecap="round"
id="g4">
<path
d="M20 2 C12.5 7.8 12.5 17.2 20 23"
id="path1" />
<path
d="M52 2 C59.5 7.8 59.5 17.2 52 23"
id="path2" />
<path
d="M27 6.5 C22.8 10 22.8 15 27 18.5"
id="path3" />
<path
d="M45 6.5 C49.2 10 49.2 15 45 18.5"
id="path4" />
</g>
<circle
cx="36"
cy="10.5"
r="5.2"
fill="#0F150F"
id="circle4" />
<rect
x="33.6"
y="14"
width="4.8"
height="11"
rx="2.4"
fill="#0F150F"
id="rect4" />
<rect
x="0"
y="23"
width="72"
height="35"
rx="10.5"
fill="#0F150F"
id="rect5" />
<path
d="M22 54 L22 64 L36 56 Z"
fill="#0F150F"
id="path5" />
<path
d="m 18.493652,47.099998 h 2.755127 v -3.848144 l 1.788575,-1.969238 3.821044,5.817382 h 3.260987 l -5.176026,-7.633056 5.031495,-5.826416 h -3.369385 l -3.297119,3.866211 c -0.894288,1.083984 -1.517579,1.933105 -2.104737,2.872558 l 0.04517,-3.062256 v -3.676513 h -2.755127 z m 18.057373,0.198731 c 3.27002,0 5.194092,-1.580811 5.194092,-4.028809 0,-2.2583 -1.752441,-3.41455 -4.019775,-3.938476 l -1.219483,-0.298096 c -1.138183,-0.270996 -2.149902,-0.695557 -2.149902,-1.698242 0,-0.90332 0.794922,-1.553711 2.204102,-1.553711 1.38208,0 2.240234,0.623291 2.339599,1.698242 h 2.664795 c -0.04517,-2.366699 -1.996338,-4.019775 -4.977295,-4.019775 -2.926758,0 -5.058594,1.625976 -5.058594,4.055908 0,1.960205 1.364014,3.107422 3.640381,3.658447 l 1.481446,0.370362 c 1.463379,0.361328 2.321533,0.785888 2.321533,1.707275 0,1.020752 -0.975586,1.716309 -2.447998,1.716309 -1.490479,0 -2.583496,-0.677491 -2.673828,-2.041504 h -2.682862 c 0.0813,2.863525 2.149903,4.37207 5.383789,4.37207 z m 6.503907,-11.372803 h 4.11914 v 11.174072 h 2.76416 V 35.925926 h 4.110108 v -2.2854 H 43.054932 Z"
id="text5"
style="font-weight:700;font-size:18.5px;font-family:Inter, Arial, sans-serif;text-anchor:middle;fill:#5fd63a"
aria-label="KST" />
</g>
</svg>

After

Width:  |  Height:  |  Size: 3.1 KiB

+156 -8
View File
@@ -3,25 +3,173 @@ title: AirScout Integration
icon: ✈️
category: Aircraft Scatter
since: "1.26"
summary: Use AirScout AP predictions in candidate evaluation, the timeline and sked planning.
description: KST4Contest receives aircraft scatter information from AirScout and relates AP timing to active ON4KST stations.
summary: Request station-specific aircraft-scatter information from AirScout and include the returned AP timing in the user list, timeline and candidate priority.
description: KST4Contest sends active station paths to AirScout, receives matching aircraft information and relates the result to the current ON4KST operating context.
tagsList:
- AirScout
- airplane scatter
- aircraft scatter
- VHF contest
- AP windows
- VHF
- UHF
- SHF
- contest
related:
- timeline
- priority-score
- sked-reminder
---
## Airplane scatter in the operator workflow
## Why connect AirScout to the chat client?
Aircraft reflections can create short but valuable contact opportunities.
An aircraft-scatter opportunity is useful for a limited time. AirScout can calculate the path and identify suitable aircraft, but it does not know which of the many stations in the ON4KST chat currently matters to the operator.
KST4Contest helps combine ON4KST chat activity with AirScout-based propagation awareness.
KST4Contest provides this missing context. It sends relevant active stations to AirScout and assigns the returned aircraft information to the corresponding chat members.
## From candidate to sked decision
The responsibilities remain separate:
AirScout information can support the decision whether a candidate station should be called immediately, scheduled later or monitored for a better window.
- AirScout obtains the aircraft data and evaluates the reflection geometry.
- KST4Contest selects the station paths to request.
- KST4Contest relates the returned timing to messages, candidate priorities and skeds.
KST4Contest does not download ADS-B data and does not calculate the aircraft geometry itself.
## Which stations are sent to AirScout?
KST4Contest updates the AirScout requests every 60 seconds. A station is included only if:
- AirScout communication is enabled;
- the station has a usable callsign and locator;
- its distance is known;
- its QRB is below the configured maximum QRB; and
- a usable propagation band can be determined.
Active chat variants of the same base callsign are combined for the frequency decision. The path itself is requested once instead of sending duplicate calculations for every visible suffix or chat-category entry.
KST4Contest also updates the AirScout watchlist. Stations which are no longer active or no longer meet the conditions are therefore not intended to remain permanent watchlist targets.
## How is the AirScout band selected?
> Automatic station-specific band selection is included in Nightly / v1.42. A fixed configured AirScout band remains available as a manual fallback.
In **Auto per station** mode, KST4Contest uses the same propagation-frequency resolver as the internal path analysis. The sources are evaluated in the following order:
1. the most recently detected QRG of the station;
2. a band explicitly stated in the name of one of its active chat entries;
3. 432 MHz when the station is present in both the VHF/UHF and microwave categories and 432 MHz is enabled locally;
4. the lowest locally enabled fallback band belonging to the supported chat category.
Only bands enabled for the local station are eligible. A manual NOT-QRV mark removes the corresponding band before the selection is made.
Recent detected frequencies are preferred because the path should normally be evaluated for the band on which the contact is actually intended. A category alone is weaker evidence: it describes a range of possible activity, not necessarily the current operating band of one station.
Unsupported ON4KST categories are ignored. They must not silently turn into a 144 MHz request merely because no better information is available.
If no usable result remains, KST4Contest omits the AirScout request for that station.
## What does AirScout return?
AirScout replies with the aircraft currently considered relevant for the requested path. For each aircraft, KST4Contest receives information including:
- the aircraft identifier;
- the AirScout size category;
- the distance to the expected reflection point;
- the potential reported by AirScout; and
- the remaining time until the expected arrival.
The aircraft are ordered by their reported potential and, where this is equal, by arrival time.
The result is assigned to every active chat variant of the corresponding base callsign. A station logged in as `CALLSIGN`, `CALLSIGN-2` or `CALLSIGN-432` therefore receives the same path information without merging the individual message targets.
![AirScout information in the station overview](/manual/assets/priority_score_overview.png)
## How does the result affect KST4Contest?
AirScout information is used in several places:
- The **AP** column shows the next available aircraft for a station.
- The **Further Info** section provides the aircraft information for the selected station.
- AP candidates can appear on the 30-minute timeline.
- A station with available aircraft receives an additional Priority Score contribution.
- An aircraft expected within the next few minutes raises the score further.
- The `FIRSTAP` and `SECONDAP` variables can insert the information into a message.
The percentage reported by AirScout is not interpreted as a contact probability. In particular, a displayed value of 100% does not mean that a QSO will succeed.
![AirScout candidates and skeds on the timeline](/manual/assets/sked_timeline.png)
## Priority and timing are separate questions
The Priority Score currently considers whether AirScout has reported usable aircraft and how soon the earliest aircraft is expected. The detailed potential value is used for the AP display and the timeline colour, but it is not converted directly into a percentage-based score.
This distinction is intentional. The AirScout value describes the aircraft geometry known to AirScout. The complete contest decision also depends on the band, antenna direction, activity of the remote station, Worked state and any existing sked.
In plain terms: an aircraft may make the path interesting. It does not make the remote station ready.
## Show the selected path in AirScout
The direction button of the selected station can send an `ASSHOWPATH` request to AirScout. AirScout then opens or updates the corresponding path display.
The request uses:
- the configured AirScout server identifier;
- the configured KST4Contest client identifier;
- the selected propagation frequency;
- the local callsign and locator; and
- the complete callsign and locator of the selected station.
The local ON4KST suffix is removed before the path request because AirScout expects the actual station callsign rather than a chat-specific login suffix.
If the selected station has no usable locator or no propagation frequency can be determined, the request is omitted. Opening an impressive empty AirScout window would not add much information.
## Several clients in the same network
The default identifiers are:
| Setting | Default |
|---|---|
| AirScout server identifier | `AS` |
| KST4Contest client identifier | `KST` |
| UDP port | `9872` |
The server and client identifiers are configurable. This matters when several KST4Contest or AirScout instances are operated in the same station network.
Each KST4Contest instance should use a distinct client identifier. Incoming AirScout replies are accepted only when the server and client identifiers exactly match the configured values. The comparison is case-sensitive.
This keeps a reply for one operating position from being assigned to another client merely because both listen on the same UDP network.
> Strict reply filtering by the configured client/server pair is included in Nightly / v1.42.
## AP variables in messages
The selected station can be referenced through two message variables:
| Variable | Result |
|---|---|
| `FIRSTAP` | Description and arrival time of the first aircraft |
| `SECONDAP` | Description and arrival time of the second aircraft |
If no aircraft is available, `FIRSTAP` returns `no ap available`. If no second aircraft exists, `SECONDAP` is replaced with an empty string.
The absence of a second aircraft is a normal result and does not prevent editing or sending the message.
## What the integration cannot guarantee
The result depends on several external and derived inputs:
- the aircraft data available to AirScout;
- the AirScout configuration and calculation;
- the locator assigned to the remote station;
- the band or frequency selected by KST4Contest;
- the age of detected QRG information; and
- the actual operating situation at the remote station.
A missing aircraft in KST4Contest does not prove that the path is unusable. It may also mean that AirScout returned no matching result, the station was outside the configured QRB range, the locator was missing or no suitable band could be derived.
Conversely, a reported aircraft does not guarantee sufficient signal strength or a completed contact.
[Read the complete AirScout setup in the manual.](/manual/en/airscout-integration/)
[Read how the AP information affects the timeline.](/features/timeline/)
[Open the AirScout project on GitHub.](https://github.com/dl2alf/AirScout)
+154 -7
View File
@@ -3,23 +3,170 @@ title: Dual Chat Categories
icon: 💬
category: ON4KST Chat
since: "1.26"
summary: Log in to two ON4KST categories and handle both message streams in one station list and interface.
description: KST4Contest combines two ON4KST chat categories while retaining the category required for messages and station context.
summary: Monitor two ON4KST categories in one interface while preserving the complete callsign and category required for correct message routing.
description: KST4Contest combines two ON4KST chat sessions, keeps individual logins separate and shares station-related Worked, band and priority information through the normalised base callsign.
tagsList:
- ON4KST
- dual chat
- multi-channel login
- callsign suffix
- VHF
- UHF
- SHF
- microwave contest
related:
- priority-score
- log-sync
- airscout
---
## Two categories, one workflow
## Why use two chat categories?
KST4Contest can operate with two ON4KST chat categories at once.
VHF, UHF and microwave activity is not always concentrated in one ON4KST category. An operator may need to follow one category for the lower bands and another for microwave operation.
This is useful when contest activity spans VHF/UHF and microwave operation.
Opening two unrelated chat clients would show both message streams, but every comparison between them would remain manual. Worked status, band information, active stations and sked context would still be distributed across separate windows.
## Less window switching
KST4Contest therefore opens up to two ON4KST chat sessions and processes both in one operating context.
The operator can keep more information visible without constantly changing tools.
![Primary and secondary chat settings](/manual/assets/client_settings_window_station.png)
## Two connections remain two connections
The primary and secondary chat sessions retain their own:
- ON4KST chat category;
- login callsign;
- public message stream;
- destination category for outgoing messages; and
- active login entries.
The second session can use the same local callsign as the primary session or a separately configured callsign. A different login may be useful when the station uses category- or band-specific suffixes.
Combining the display does not turn both sessions into one ON4KST connection. Messages must still be sent through the category in which the intended destination is active.
## What identifies an active chat member?
An active login is identified by:
1. the complete visible callsign, including its suffix; and
2. the ON4KST chat category.
Both parts are required.
Consider the following active entries:
| Complete callsign | Chat category | Active entity |
|---|---:|---|
| `9A0BB-2` | 1 | separate |
| `9A0BB-70` | 1 | separate |
| `9A0BB-23` | 2 | separate |
| `9A0BB-13` | 2 | separate |
All four entries belong to the same base callsign, but they are four different chat logins. Joining, updating or leaving the chat affects only the corresponding complete callsign in the corresponding category.
This is particularly important for `9A0BB-2` and `9A0BB-70`: because both use the same category, the category alone cannot distinguish them.
> Correct separation of several suffix variants within the same category is included in Nightly / v1.42 and fixes [Issue #73](https://github.com/praktimarc/kst4contest/issues/73).
## How are messages routed?
When a row is selected, KST4Contest retains both the complete callsign and its category. A private message is addressed to that complete callsign and sent through the corresponding chat session.
Selecting `9A0BB-70` in category 1 therefore creates a message for `9A0BB-70` in category 1. It is not silently reduced to `9A0BB`, and it is not sent through category 2 merely because another variant is active there.
The same distinction is used for:
- incoming private messages;
- outgoing message echoes;
- public messages addressed to the local station;
- station selection from the user list;
- sked reminder messages; and
- leaving or updating an active chat entry.
The different variants do not have to be able to send messages to each other. That is not the purpose of the function. They must remain correctly reachable by other stations and receive the messages addressed to their respective login.
## What is shared through the base callsign?
Some information describes the radio station rather than one temporary chat login. This information is aggregated through the normalised base callsign.
For the examples above, the common base callsign is `9A0BB`.
The shared station context includes:
- global Worked status;
- Worked status per band;
- manually assigned NOT-QRV marks;
- known band opportunities derived from the active variants;
- the Priority Score; and
- stored contest state in the internal database.
A QSO with `9A0BB-70` therefore also marks the corresponding base callsign as worked for the other active suffix variants. It would be misleading to present `9A0BB-2` as a completely new station immediately afterwards.
Per-band information is still retained. Working the station on 70 MHz does not mark it as worked on 23 cm. The common base callsign links the variants; the band remains a separate dimension.
## Why are band hints combined?
A station may use its visible login names to describe the available bands:
- `9A0BB-2`
- `9A0BB-70`
- `9A0BB-23`
- `9A0BB-13`
KST4Contest can evaluate these active variants together when deriving possible bands. Recent QRG information and band designators in the name fields can contribute as well.
This allows the user list, the `a` and `B+` indicators, the **New bands** filter and the automatic propagation-frequency selection to use information which may be distributed across the two chat categories.
A manual NOT-QRV mark still takes precedence. An automatically detected suffix or name is evidence of possible activity, not permission to ignore an explicit correction.
## Why is the Priority Score not duplicated?
The Priority Score represents the operating priority of the station, not the number of chat logins it happens to use.
KST4Contest therefore calculates the score for the normalised base callsign and projects it to the active variants. Several suffixes do not create several independent priority candidates merely by being logged in more than once.
The individual rows remain selectable because the correct message destination still matters.
In plain terms: one station should not occupy half the priority list, but the operator must still be able to contact the correct login.
## Categories are context, not proof of a band
A chat category describes the general operating area of that chat. It does not prove that every station in the category is currently QRV on every associated band.
KST4Contest therefore uses stronger station-specific information where available:
1. a recently detected QRG;
2. an explicit band designator in the station name or suffix;
3. the locally enabled bands;
4. stored Worked and NOT-QRV information; and
5. only then a supported category fallback where the function requires one.
Categories unrelated to the supported VHF, UHF, microwave or EME workflows are ignored by propagation functions which cannot derive a meaningful result from them. They must not cause a fallback to an arbitrary band.
## What remains separate?
Sharing the station context does not merge everything associated with the base callsign.
The following remain tied to the individual login or message:
- complete message destination;
- chat category;
- public message stream;
- visible callsign suffix;
- join and leave state;
- the specific row selected by the operator; and
- message history associated with that login and category.
This distinction is the basis of the dual-chat implementation: operational information may be shared where it describes the same radio station, while communication remains attached to the actual ON4KST login.
## Practical limitations
The shared base-callsign model assumes that suffix variants separated by `-` belong to the same underlying amateur-radio station. That is appropriate for common logins such as `-2`, `-70`, `-144` or `-432`.
KST4Contest cannot determine whether two operators behind those logins are using one station, several independently operated stations or a distributed contest setup. Worked and band information is therefore shared at callsign level, while the operator remains responsible for selecting the correct chat destination.
[Read how both chat categories are configured.](/manual/en/configuration/#login-and-chat-categories)
[Read how Worked and band information is derived.](/manual/en/features/#worked-callsigns-new-bands-and-new-grid-squares)
[Read how suffixed callsigns are handled in skeds.](/features/sked-reminder/)
+218 -11
View File
@@ -1,24 +1,231 @@
---
title: DXCluster Server
title: Local DX Cluster Server
icon: 📡
category: Radio Workflow
category: Logger Integration
since: "1.23"
summary: Send direction warnings as DX Cluster spots to compatible logging software when a usable QRG is known.
description: The built-in DX Cluster server forwards KST4Contest direction warnings and known frequency information to compatible contest loggers.
summary: Forward detected directional opportunities and their known frequencies as local DX Cluster spots to compatible contest loggers.
description: KST4Contest provides a local TCP DX Cluster server which turns selected ON4KST direction and frequency information into spots for a logger bandmap.
tagsList:
- DXCluster
- ham radio
- contest
- DX Cluster
- bandmap
- ON4KST
- QRG detection
- UCXLog
- N1MM+
- contest logger
related:
- log-sync
- priority-score
- dual-chat
---
## What kind of DX Cluster is this?
## More situational awareness
KST4Contest does not connect to a public DX Cluster and does not import external spots.
DXCluster information can support contest operators by adding another source of activity information.
Instead, it provides a local TCP server to which a compatible contest logger can connect as a DX-Cluster client. KST4Contest uses that connection to forward selected information already detected in the ON4KST chat.
## Integrated workflow
The purpose is practical: when a station appears to be pointing in the local direction and its QRG is known, the information can appear directly in the logger bandmap. The operator no longer has to read the frequency in the chat, remember it and enter it again in the logger.
The goal is not to open another isolated tool, but to connect activity information with the wider KST4Contest workflow.
That is the entire idea. The function is a bridge between the KST4Contest analysis and the logger, not another source of general DX traffic.
## When is a spot generated?
A real spot is generated only when all of the following conditions are met:
1. A directed message between two other stations has been detected.
2. Valid locators are available for the sender and receiver.
3. The sender is within the configured maximum QRB.
4. The local station lies inside the assumed antenna corridor of the sender.
5. A usable frequency is known for the sender.
6. The local DX Cluster server is enabled.
7. At least one DX-Cluster client is connected to the server.
KST4Contest deliberately does not forward every frequency mentioned in the chat. Otherwise, a function intended to reduce distraction would produce its own local spot flood.
## How is the directional opportunity derived?
Assume that station A sends a directed message to station B. KST4Contest uses the direction from A to B as an approximation of the current antenna direction of station A.
It then compares:
- the direction from A to B; and
- the direction from A to the local station.
The configured antenna beamwidth is treated as the complete angle. Half of the value is applied to either side of the direction from A to B.
For a configured beamwidth of `70°`, the assumed corridor is therefore `±35°`.
If the local station lies inside this corridor, KST4Contest marks the sender as a directional opportunity. When a QRG is also available, the local DX Cluster spot can be generated immediately.
This is a geometric approximation. ON4KST does not transmit the actual antenna direction or beamwidth of the remote station, so KST4Contest uses the locally configured beamwidth as a practical substitute.
Terrain, propagation and the actual operating intention of the sender are not part of this calculation.
## Which frequency is used?
KST4Contest uses the same QRG detection that supplies the frequency column and other band-related functions.
Complete frequencies determine their band directly:
```text
50.200
70.250
144.205
432.088
1296.338
10368.100
24048.100
```
The value is converted into the kHz representation expected by the DX Cluster protocol:
| Chat frequency | DX Cluster frequency |
|---|---:|
| `50.200` | `50200.0` |
| `144.205` | `144205.0` |
| `1296.338` | `1296338.0` |
| `10368.100` | `10368100.0` |
| `24048.100` | `24048100.0` |
An additional sub-kHz group is retained. For example, `144.205.2` becomes `144205.2`.
## Relative QRG information
A relative frequency contains only the part inside a band:
```text
.205
,205
qrg 205
freq is 205
on 205
```
KST4Contest determines the missing band in this order:
1. a recent band context detected for the same station during the previous 30 minutes;
2. the most recently updated plausible context if several bands are known;
3. the configured **Fallback band for relative QRG detection**.
Example:
```text
Configured fallback: 144 MHz
Recent complete QRG of the station: 432.088 MHz
New message from the same station: .100
Result: 432.100 MHz
DX Cluster value: 432100.0 kHz
```
Without the recent station-specific context, the same `.100` would use the configured fallback and become `144.100 MHz`.
A bare three-digit value is accepted only when the surrounding text identifies it as a frequency. This prevents values such as `599`, a bare band name or the number of completed QSOs from becoming plausible-looking spots.
## What does the spot contain?
The generated spot contains:
- the configured spotter callsign;
- the normalised frequency;
- the complete callsign of the detected station;
- the sender's locator;
- up to two optional AirScout entries; and
- the current UTC time.
An example comment with AirScout information may look like this:
```text
JN49GL , AP: 1min, 100%; 4min, 75%
```
AirScout information is optional. A missing AirScout response does not prevent the spot from being sent.
> AP-independent spot creation, corrected sender-locator handling and band-generic frequency conversion are included in Nightly / v1.42.
## Connecting a logger
Open the **Notification** tab in the KST4Contest settings.
![Notification and local DX Cluster settings](/manual/assets/client_settings_window_notification.png)
Configure:
1. **Enable the local DX Cluster server …**
2. A free TCP port. The default is `8000`.
3. The fallback band used for relative QRG information.
4. A spotter callsign.
The logger is then configured as the DX-Cluster client:
| Setting | Same computer | Separate logger computer |
|---|---|---|
| Host | `127.0.0.1` | IP address of the KST4Contest computer |
| Port | Configured KST4Contest TCP port | Configured KST4Contest TCP port |
| Login | Any callsign if required | Any callsign if required |
| Password | Not required | Not required |
The spotter callsign should preferably differ from the contest callsign. Some loggers suppress or specially handle spots which appear to originate from the local station. A spot can therefore be generated correctly and still remain invisible in the bandmap.
## Several connected clients
The local server can retain several DX-Cluster client connections. A generated spot is sent to every client currently connected.
KST4Contest sends an empty keep-alive line every 30 seconds so idle connections are less likely to be closed unnoticed. Clients which disconnect while a spot is being sent are removed from the active connection list.
Changing the configured port while connected restarts the local server. Existing logger connections must then reconnect to the new port.
## Network boundary
The server does not authenticate the login supplied by a DX-Cluster client. It is intended for the local computer or a trusted station network.
When the logger runs on another computer:
- use the IP address of the KST4Contest computer;
- allow the configured TCP port through the local firewall; and
- do not expose the server directly to the internet.
A missing password is acceptable inside the intended station network. It is not a security concept for a public service.
## Testing the connection
Use **Send test spot** after the logger has connected.
A successful test confirms that at least one client received the generated spot. If the test works but real spots do not appear, the TCP connection is probably not the problem. In that case, check the conditions used for the actual directional opportunity:
- Were valid locators available?
- Was the sender within the maximum QRB?
- Was the direction inside the configured beamwidth?
- Was a valid frequency known?
- Did a station-specific band context change the relative QRG?
## What the spot means — and what it does not
The spot means that KST4Contest detected a plausible directional opportunity and knew a frequency for the sender.
It does not prove:
- the actual antenna direction of the station;
- that the station intends to work the local operator;
- that the path is currently open;
- that the frequency is still unchanged; or
- that a QSO will succeed.
The logger may tune the transceiver to the spot frequency, depending on its own configuration. The operator still decides whether calling the station makes sense.
In plain terms: KST4Contest can remove the typing. It cannot remove the judgement.
## Tested loggers
The local DX Cluster interface has been used with:
- UCXLog
- N1MM+
Other loggers may work if they can open a normal TCP connection to a DX Cluster server and accept conventional `DX de ...` spot lines.
[Read the complete setup and troubleshooting section in the manual.](/manual/en/dx-cluster-server/)
[Read how directional opportunities are derived.](/manual/en/features/#sked-direction-highlighting)
[Read how relative QRG information is configured.](/manual/en/configuration/#fallback-band-for-relative-qrg-detection)
+100 -9
View File
@@ -1,28 +1,119 @@
---
layout: base.njk
title: KST4Contest Features
description: Contest-optimized ON4KST features for VHF, UHF and SHF operation.
lang: en
title: KST4Contest Functions
description: Technical overview of the KST4Contest functions for ON4KST chat processing, candidate evaluation, sked planning, AirScout and logger integration.
---
<section class="hero">
<p class="badge">Features</p>
<h1>Contest tools, not just chat windows.</h1>
<p class="eyebrow">Functions</p>
<h1>How KST4Contest supports the contest workflow</h1>
<p class="lead">
KST4Contest combines ON4KST chat, candidate scoring, AirScout workflow,
sked handling, log synchronization and operator decision support.
KST4Contest combines ON4KST messages with station, band, Worked, sked,
AirScout and logger information. The individual functions use this shared
context instead of treating every message or interface as an isolated
event.
</p>
<p>
Some information is received directly from another program. Other
information must be derived from chat messages, station names or the
current operating state. The distinction matters: a detected band or a
calculated priority is useful context, but not automatically a confirmed
fact.
</p>
<div class="actions">
<a class="button" href="/manual/en/features/">Read the technical description</a>
<a class="button secondary" href="/manual/en/configuration/">Open configuration</a>
<a class="button ghost" href="/download/">Download KST4Contest</a>
</div>
</section>
<section class="section">
<div class="section-heading">
<p class="eyebrow">Shared context</p>
<h2>Why the functions affect each other</h2>
<p>
A newly detected frequency can change the known bands of a station. This
can affect its Worked state, filters, priority, map path and a later sked
handover. The same principle applies to information received from a
logger or entered manually.
</p>
</div>
<div class="grid">
{% for feature in collections.features %}
<article class="card">
<h3>Received information</h3>
<p>
ON4KST messages, logger packets, Win-Test network data and AirScout
responses provide information at different levels of detail. Missing
fields are not automatically equivalent to negative information.
</p>
</article>
<article class="card">
<h3>Derived information</h3>
<p>
Bands, frequencies, activity and candidate priorities may be derived
from several sources. Explicit NOT-QRV information overrules a merely
inferred band opportunity.
</p>
</article>
<article class="card">
<h3>Operator decision</h3>
<p>
Scores, filters, AP windows and path assessments reduce the amount of
information that must be evaluated manually. They do not guarantee a
contact or replace checking the actual operating situation.
</p>
</article>
</div>
</section>
<section class="section">
<div class="section-heading">
<p class="eyebrow">Function overview</p>
<h2>Functions in their intended order</h2>
<p>
The pages below explain the operating problem behind each function, the
information it uses and the limitations that remain.
</p>
</div>
<div class="grid">
{% for feature in collections.sortedFeatures %}
<article class="card feature-card">
<div class="feature-icon">{{ feature.data.icon }}</div>
<p class="eyebrow">{{ feature.data.category }}</p>
<h3><a href="{{ feature.url }}">{{ feature.data.title }}</a></h3>
<h3>
<a href="{{ feature.url }}">{{ feature.data.title }}</a>
</h3>
<p>{{ feature.data.summary }}</p>
<a href="{{ feature.url }}">Learn more →</a>
<a href="{{ feature.url }}">Read how it works →</a>
</article>
{% endfor %}
</div>
</section>
<section class="section">
<div class="cta-panel">
<p class="eyebrow">Technical details</p>
<h2>The manual remains the authoritative description</h2>
<p>
These pages provide a practical overview. Configuration parameters,
interface requirements, exact behaviour and version-specific limitations
are documented in the manual. Where the short description and the manual
differ, the manual should be corrected first. Two competing descriptions
of the same function would not improve matters.
</p>
<div class="actions">
<a class="button" href="/manual/en/">Open the English manual</a>
<a class="button secondary" href="/manual/de/">Deutsches Handbuch</a>
</div>
</div>
</section>
+209 -7
View File
@@ -3,21 +3,223 @@ title: Macros and Variables
icon: ⚡
category: Operator Speed
since: "1.0"
summary: Build recurring chat messages from configurable text blocks and variables such as the current QRG or locator.
description: KST4Contest macros combine reusable message text with values taken from the current station, frequency and operating context.
summary: Insert recurring text through shortcut buttons or snippets and add current QRG, locator, heading, station-name and AirScout information when the message is used.
description: KST4Contest provides configurable shortcut buttons, station-addressed snippets and message variables for information which would otherwise have to be typed repeatedly.
tagsList:
- macros
- message variables
- text snippets
- shortcuts
- ON4KST
- operator workflow
related:
- sked-reminder
- airscout
- dual-chat
- sked-reminder
---
## Faster messages
## Three different mechanisms
Macros reduce repetitive typing during active contest operation.
KST4Contest uses three related but distinct mechanisms:
## More consistent operation
| Mechanism | Purpose |
|---|---|
| Shortcut | Inserts a configured text through a button in the main window |
| Snippet | Prepares or extends a message for the selected station |
| Variable | Replaces a reserved placeholder with current operating information |
Variables help keep messages structured and reduce manual errors.
Shortcuts and snippets store text. Variables add values which may change while the program is running.
This distinction matters. A shortcut such as `pse sked?` always inserts the same text. A shortcut containing `MYQRG` inserts the QRG which is current when the shortcut is used.
## Shortcut buttons
Each entry configured under **Shortcut Settings** creates a button in the main window.
Pressing the button appends its text to the send field. Variables contained in the shortcut are resolved against the current station and operating context.
Typical shortcuts are:
```text
pse sked?
rrr
tnx
pse call me at MYQRGSHORT
/SETNAME MYQRG
```
Shortcuts are useful for short expressions which are required frequently and are not necessarily addressed to a particular station.
`MYQRG` and `SECONDQRG` are also recognised as frequency buttons and insert the corresponding current QRG.
## Text snippets
Snippets are longer text blocks intended primarily for communication with a selected station.
They are available through:
- the context menu of the user list;
- the context menus of the public and private message tables; and
- `Ctrl+1` through `Ctrl+0` for the first ten configured snippets.
When a station is selected, a keyboard snippet prepares a directed message using the complete visible callsign:
```text
/cq CALLSIGN snippet text
```
A suffixed callsign such as `9A0BB-70` remains `9A0BB-70`. Its chat category is retained for the later transmission, so the snippet is not accidentally sent through the other active category.
The prepared message is not sent automatically. It remains in the send field and can be checked or edited before pressing `Enter` or **TX**.
## When are variables resolved?
Variables inserted through a shortcut or snippet are resolved when that text is inserted.
Variables typed or pasted directly into the send field are resolved immediately before the message is placed in the transmission queue. This provides a second controlled resolution point and ensures that manually entered variables work as well.
Station-specific variables always refer to the currently selected station. They are not derived from a callsign which was typed manually somewhere inside the message.
Variable names are case-sensitive and must be written in uppercase.
## Global variables
Global variables depend only on the local station and its current configuration.
| Variable | Replacement |
|---|---|
| `MYQRG` | Current QRG of the primary chat category |
| `MYQRGSHORT` | First seven characters of the primary QRG |
| `SECONDQRG` | Current QRG of the second chat category |
| `MYLOCATOR` | Complete configured locator of the local station |
| `MYLOCATORSHORT` | First four characters of the local locator |
| `MYCALL` | Configured local login callsign |
| `MYQTF` | Current antenna heading in degrees |
Example:
```text
cq at MYQRGSHORT, qtf MYQTF, loc MYLOCATOR
```
may become:
```text
cq at 144.388, qtf 135, loc JO51IJ
```
`MYQRG` always refers to the primary category and `SECONDQRG` always refers to the second category. Their meaning does not change merely because a station from the other chat category is selected.
The QRG values may originate from logger synchronisation or from the corresponding manually editable QRG fields.
`MYQTF` is a numeric heading. It is not converted into words such as `north` or `south-west`.
## Variables requiring a selected station
The following variables use information belonging to the selected remote station:
| Variable | Replacement |
|---|---|
| `QRZNAME` | Name shown for the selected station, or its complete callsign if no name is available |
| `FIRSTAP` | Description and arrival time of the first AirScout aircraft |
| `SECONDAP` | Description and arrival time of the second AirScout aircraft |
Example:
```text
Hi QRZNAME, FIRSTAP, pse lsn at MYQRGSHORT
```
may become:
```text
Hi David, a very big AP in 2 min, pse lsn at 144.388
```
If AirScout reports no aircraft for the selected station, `FIRSTAP` becomes:
```text
no ap available
```
If no second aircraft is available, `SECONDAP` becomes an empty string.
When no station is selected, `QRZNAME`, `FIRSTAP` and `SECONDAP` remain visible in the text. They are deliberately not removed, because an unresolved placeholder is easier to notice than a plausible-looking but incomplete message.
Select the intended station before using these variables and check that no unresolved placeholder remains before sending.
## Variables in automatic beacons
A public beacon has no selected remote station. It can therefore use only global variables:
- `MYQRG`
- `MYQRGSHORT`
- `SECONDQRG`
- `MYLOCATOR`
- `MYLOCATORSHORT`
- `MYCALL`
- `MYQTF`
`QRZNAME`, `FIRSTAP` and `SECONDAP` must not be used in a beacon.
![Beacon settings for both chat categories](/manual/assets/client_settings_window_beacon.png)
Each chat category has its own enable setting and message template. Both categories use the same timer interval. The second beacon is sent only when the second chat login and its beacon are enabled.
Global variables are evaluated again on every timer run. A QRG changed by the logger can therefore be included in the next beacon without editing its template.
The completely resolved beacon text must not exceed 120 characters. The configured minimum interval is one minute.
A suitable template is:
```text
cq at MYQRGSHORT, qtf MYQTF, loc MYLOCATOR
```
For the second category, use `SECONDQRG` if that category operates on a different QRG.
## Practical workflow
A typical sequence is:
1. Select the intended station.
2. Press `Ctrl+1` to prepare a directed snippet.
3. Check the complete callsign and the resolved values.
4. Adjust the message if the station proposed another QRG.
5. Press `Enter` or **TX**.
For example, the configured snippet:
```text
Hi QRZNAME, pse sked? I call at MYQRGSHORT
```
can produce:
```text
/cq DL1ABC-432 Hi Peter, pse sked? I call at 432.088
```
The complete callsign identifies the message destination. The current QRG and station name reduce repetitive typing but do not decide whether the information is still operationally correct.
## Operational limitations
Variables reproduce the information currently known to KST4Contest. They do not verify that it is still correct.
In particular:
- a logger-supplied QRG may already have changed;
- a manually entered QRG remains in use until it is changed again;
- the selected station may differ from a manually typed `/cq` target;
- AirScout may have no current aircraft information; and
- an unresolved station variable remains visible when no station is selected.
The send field therefore remains editable after inserting a shortcut or snippet.
In plain terms: the variables remove repeated typing. The operator still checks the message.
[Read the complete macro and variable reference in the manual.](/manual/en/macros-and-variables/)
[Open the shortcut and snippet configuration.](/manual/en/configuration/#shortcut-settings)
[Read how the AirScout values are obtained.](/features/airscout/)
+315 -25
View File
@@ -3,56 +3,346 @@ title: Priority Score System
icon: 🎯
category: Contest Workflow
since: "1.40"
summary: Rank active base callsigns using known band, direction, activity, AirScout, reply and sked information.
description: KST4Contest excludes stations with no known remaining band opportunity and orders the other active candidates using the context already available to the client.
summary: Calculate one priority per base callsign, exclude known unusable band combinations and order the remaining active stations by band, distance, direction, activity, AirScout, reply and sked context.
description: KST4Contest combines information which would otherwise have to be evaluated separately and uses the resulting score to identify stations worth examining next.
tagsList:
- ON4KST
- Priority Score
- priority candidates
- band opportunity
- VHF
- UHF
- SHF
- contest
- priority candidates
- contest workflow
related:
- timeline
- airscout
- sked-reminder
- dual-chat
---
## The problem behind the score
## What question does the score answer?
An ON4KST user list shows who is logged in. During a contest, the more useful question is which station should be examined next.
An ON4KST user list initially shows which stations are logged in. During a contest, that is only the beginning of the decision.
Answering that question manually means repeatedly combining Worked status, possible bands, distance, antenna direction, recent activity, AP opportunities and scheduled contacts. This remains manageable with a short list. It becomes less reliable after several hours of contest operation, especially when multiple bands and chat categories are involved.
For every possible contact, the operator would otherwise have to combine questions such as:
## How candidates are selected
- Has the station already been worked?
- Is another common band still available?
- Does the current antenna direction fit?
- Is the station active in the chat?
- Is an aircraft-scatter opportunity approaching?
- Has the station replied quickly before?
- Is there an agreed sked?
KST4Contest first checks whether a known common and unworked band opportunity remains. Locally enabled bands, recent QRG detections, band designators in station names, Worked information and manual NOT-QRV marks are evaluated together.
KST4Contest combines this existing context into one relative Priority Score.
A known incompatibility or an already completed set of possible bands produces a score of `0` and removes the station from the priority list. Missing band information alone does not. Unknown is not the same as impossible.
The score answers:
The remaining stations are ranked using several independent hints, including:
> Which active station should I examine next?
- distance and the configured maximum QRB,
- the current antenna direction and beamwidth,
- recent chat activity and reaction behaviour,
- available AirScout aircraft,
- open band opportunities, and
- the timing of scheduled contacts.
It does not answer whether a QSO will succeed.
An imminent sked receives a deliberately strong boost. Failed attempts and unanswered calls reduce the score.
## Eligibility comes before weighting
## One station, several chat logins
Before adding activity, AirScout or sked points, KST4Contest checks whether a usable band opportunity is known.
Suffixes and chat categories remain separate message targets. Worked, band, NOT-QRV and score information is shared through the normalised base callsign.
All active callsign and category variants of the same base callsign are evaluated together.
This prevents a station using several band-specific logins from occupying several positions in the priority list while still allowing KST4Contest to address the correct complete callsign in the correct category.
The band calculation uses:
1. the bands enabled under **My station uses ...**;
2. QRGs detected for the remote station during the previous 30 minutes;
3. explicit band designators in the name fields of its active chat entries;
4. stored per-band Worked marks; and
5. manually assigned NOT-QRV marks.
A manual NOT-QRV mark takes precedence over an automatically detected QRG or band designator.
If bands are known for the remote station but none of them is both enabled locally and still available, the station receives a score of `0`.
The same applies when every known common band has already been worked.
## Unknown is not the same as impossible
A station is not excluded merely because no band information has been detected.
Missing information means that KST4Contest cannot currently prove which band is available. It does not prove that no common band exists.
Such a station remains eligible unless every locally enabled band has explicitly been marked NOT QRV.
Passing this eligibility check does not guarantee a place in the priority list. It only allows the normal weighting to continue. If the final calculation still results in `0`, the station remains outside the priority list.
This distinction is important. A band incompatibility is a hard reason for exclusion. A low final score is the result of the complete operating context.
## How is the score calculated?
The current calculation starts with a base value of `100`.
The following contributions are then applied in order.
### Worked and band information
| Condition | Current effect |
|---|---:|
| No supported band has been worked | `+200` |
| At least one supported band has already been worked | `150` |
| Each additional compatible offered band after the first | `+80` |
| Optional band-upgrade Priority Boost | `+180` |
The additional band count is based on offered bands which are enabled locally and not marked NOT QRV. Worked bands remain part of that general multi-band context, while at least one unworked common band is required for a known band-upgrade opportunity.
The optional Priority Boost applies only when:
- the station has already been worked on at least one band;
- another common and unworked band remains; and
- **Priority boost for band-upgrade cases** is enabled.
Without this option, an open band makes the station eligible but does not by itself guarantee a positive final score.
## Distance
When a valid QRB is available, the subtotal calculated so far is multiplied according to the distance:
| Distance | Multiplier |
|---|---:|
| Below `200 km` | `× 0.7` |
| Between `200 km` and the configured maximum QRB | `× 1.15` |
| Beyond the configured maximum QRB | `× 0.3` |
This does not mean that short or very distant contacts are impossible. It reflects the intended contest workflow: stations inside the configured working range, but not already in the very short-distance range, receive more attention.
If no QRB is available, the distance multiplier is omitted.
## AirScout information
When AirScout reports at least one reachable aircraft, the station receives `+200`.
The arrival time of the next aircraft adds:
| Expected arrival | Additional score |
|---|---:|
| `0 minutes` | `+120` |
| `1 minute` | `+60` |
| `2 minutes` | `+30` |
The AirScout potential percentage is used elsewhere for display and timeline selection. It is not converted directly into the Priority Score.
A displayed aircraft therefore indicates a time-dependent opportunity. It is not a success probability.
## Antenna direction
If the QTF to the remote station lies inside half of the configured antenna beamwidth around the current local QTF, the station receives between `+80` and `+200`.
The value rises towards the centre of the antenna direction:
- approximately `+80` at the edge of the configured beam;
- up to `+200` when both directions match.
The calculation uses the local antenna direction. It does not know the actual antenna direction of the remote station.
## Current chat activity
Recent incoming messages raise the priority:
| Activity | Score |
|---|---:|
| Last incoming line less than 60 seconds ago | `+120` |
| Last incoming line less than three minutes ago | `+60` |
Several incoming lines inside the configured momentum window add:
| Lines inside the window | Score |
|---|---:|
| At least 2 | `+60` |
| At least 4 | `+110` |
| At least 6 | `+160` |
The default momentum window is 180 seconds.
This factor identifies stations which are currently active in the chat. It does not prove that they are available for a contact with the local station.
## Positive text signals
Configured expressions such as `QRV`, `READY`, `RGR`, `OK`, `TNX` or `LSN` are treated as positive activity hints.
A detected expression remains effective for five minutes and adds `+120`.
The detector uses case-insensitive literal substring matching. It does not interpret sentence meaning or negation. A line containing `not QRV` still contains the configured substring `QRV`.
Positive text signals must therefore remain a comparatively weak hint inside the larger calculation. They are useful for recognising activity, but they are not a natural-language interpretation of the message.
## Reply behaviour
When the operator sends:
```text
/cq CALLSIGN ...
```
KST4Contest starts measuring the response time for the corresponding base callsign.
A smoothed average response time adds:
| Average response time | Score |
|---|---:|
| Below one minute | `+80` |
| Below three minutes | `+40` |
Any subsequently received public or private line from the same base callsign ends the pending measurement.
KST4Contest cannot determine whether that line was really an answer to the local operator. The value is therefore an operational approximation, not a statistically reliable reply rate.
If no line is received before the configured timeout, a No-Reply strike is added. The default timeout is 13 minutes.
Each strike divides the current subtotal by:
```text
1 + (number of strikes × 0.6)
```
No-Reply strikes accumulate during the current program run.
## Scheduled contacts
A stored sked is an operating commitment and receives a deliberately strong time-dependent contribution.
| Time relative to the sked | Effect |
|---|---:|
| More than 15 minutes before | `+40` |
| Final 15 minutes | Increasing contribution |
| Three minutes before until one minute after | `+5000` |
The strong contribution around the scheduled time is intentional. An agreed contact should not disappear from the list merely because another station happens to be very active in the chat.
The sked contribution belongs to the normalised base callsign. A sked created for `9A0BB-23` therefore also raises the common score shown for other active `9A0BB` variants.
The actual reminder destination remains the complete selected callsign in its original chat category.
## Manual Sked fail
**Sked fail** represents an explicit operator assessment that the attempted contact or path has failed.
The complete final score, including an imminent sked contribution, is multiplied by `0.15`.
Applying this penalty at the end is important. Otherwise the later `+5000` sked contribution would almost completely cancel the failure mark and leave the station at the top of the list.
The mark:
- applies to the normalised base callsign;
- affects all active suffix and category variants;
- remains active for the current program run; and
- can be removed with **Reset fail**.
The sked itself remains stored. Only its effect on the final operating priority is overruled.
## One station, several active logins
Calls such as:
```text
9A0BB-2
9A0BB-70
9A0BB-23
9A0BB-13
```
remain separate message targets.
For scoring, they are grouped through the base callsign:
```text
9A0BB
```
KST4Contest calculates one score for that base callsign and projects it to every active variant.
This prevents one physical station from occupying several positions in the priority list merely because it uses several suffixes or chat categories.
The individual rows remain separate because outgoing messages still require the complete callsign and the correct category.
## Which login is shown in the priority list?
KST4Contest selects one active login as the representative of the base callsign.
The selection order is:
1. a variant in the chat category from which the most recent inbound activity was received;
2. the most recently active variant inside that category;
3. otherwise, the most recently active variant across all categories.
The resulting Priority Candidate retains:
- the normalised base callsign;
- the complete displayed callsign; and
- the preferred chat category.
Selecting the candidate therefore leads back to an actual active login rather than an abstract database key.
## Display and operation
![Priority Score, compact candidate list and Further Info controls](/manual/assets/priority_score_overview.png)
## A decision aid, not a propagation forecast
The score appears in three places:
The score is a relative operating priority. It is not a success probability, a signal estimate or a guarantee that the remote station is ready for a QSO.
- the numerically sortable **Score** column in the user list;
- the **Further Info** section of the selected station; and
- the compact priority bar between the user list and Further Info.
Its value depends on the information available to KST4Contest, and that information may be incomplete, outdated or ambiguous. The final decision remains with the operator.
The compact bar shows the two highest-ranked candidates.
[Read the complete calculation and its limitations in the manual.](/manual/en/features/#priority-score-and-priority-list-from-v140)
The **more** button opens a separate list containing up to 15 candidates. Double-click a candidate to select it.
Only finite scores above `0` are included in the priority list. Stations with a score of `0` remain visible in the normal user list, where Worked, band and NOT-QRV information can still be examined.
The priority list is calculated from the active station model and is independent of the current table filters. A candidate may therefore appear in the priority list while its row is hidden by **New bands**, QRB, QTF or another user-list filter.
Selecting such a candidate still updates Further Info and prepares the directed message. The active filter remains unchanged.
> Correct band eligibility, base-callsign grouping, separate suffix routing, the final Sked-fail override and selection of filtered candidates are included in Nightly / v1.42.
## When is the score updated?
New calculations are requested after relevant events such as:
- incoming chat messages;
- AirScout updates;
- newly created skeds;
- log and Worked updates;
- changes to NOT-QRV marks;
- **Sked fail** and **Reset fail**; and
- outgoing `/cq` messages.
The background scheduler checks the score every three seconds. Time-dependent information is also recalculated periodically when no new event arrives.
A short delay between an event and the visible new order is therefore normal. The calculation is deliberately coalesced so that several closely spaced events do not create a separate JavaFX update for every station.
## What does the score not tell you?
The Priority Score is not:
- a probability of completing the QSO;
- a signal-strength estimate;
- a propagation forecast;
- a confirmed antenna direction of the remote station; or
- proof that the station is currently sitting at the radio.
A score of `800` is not twice as promising as a score of `400`. The values establish an order inside the current calculation; they do not form a physical scale.
Input data may also be incomplete or outdated:
- a detected QRG can be up to 30 minutes old;
- a name field may describe several bands without stating the current one;
- a chat line may be unrelated to the local station;
- an AirScout result depends on its external aircraft data and configuration; and
- an agreed sked may no longer reflect the actual situation.
In practical terms: the score keeps the available information from having to be reconstructed mentally for every station. The decision still belongs to the operator.
[Read the complete Priority Score description in the manual.](/manual/en/features/#priority-score-and-priority-list-from-v140)
[Open the related station and scoring settings.](/manual/en/configuration/#band-upgrade-hint-after-a-log-entry)
[Read how active suffix variants remain separate message targets.](/features/dual-chat/)
[Read how Priority Candidates are used on the timeline.](/features/timeline/)
+22 -3
View File
@@ -5,14 +5,33 @@ pagination:
alias: manual
permalink: "/manual/{{ manual.lang }}/{{ manual.slug }}/"
layout: base.njk
lang: "{{ manual.lang }}"
title: "{{ manual.title }} | KST4Contest Manual"
description: "KST4Contest manual page: {{ manual.title }}"
description: "{{ manual.summary }}"
---
<section class="section">
<div class="card manual-content">
<p><a href="/manual/{{ manual.lang }}/">← Back to manual overview</a></p>
<h1>{{ manual.title }}</h1>
{% if manual.lang == "de" %}
<p>
<a href="/manual/de/">← Zurück zur deutschen Handbuchübersicht</a>
</p>
{% else %}
<p>
<a href="/manual/en/">← Back to the English manual overview</a>
</p>
{% endif %}
{{ manual.content | markdown | safe }}
{% if manual.lang == "de" %}
<p>
<a href="/manual/de/">← Zurück zur deutschen Handbuchübersicht</a>
</p>
{% else %}
<p>
<a href="/manual/en/">← Back to the English manual overview</a>
</p>
{% endif %}
</div>
</section>
+89 -6
View File
@@ -1,24 +1,107 @@
---
layout: base.njk
title: KST4Contest Deutsches Handbuch
description: Deutsches Benutzerhandbuch für KST4Contest.
lang: de
title: KST4Contest Deutsches Handbuch
description: Technisches Benutzerhandbuch für Installation, Konfiguration, ON4KST-Betrieb, AirScout, Log-Synchronisation und die weiteren Funktionen von KST4Contest.
---
<section class="hero">
<p class="eyebrow">Dokumentation</p>
<h1>Deutsches Handbuch</h1>
<p>Das Handbuch wird zentral in GitHub gepflegt und als Wiki, PDF und Online-Dokumentation veröffentlicht.</p>
<p>
Dieses Handbuch beschreibt nicht nur die Bedienelemente von KST4Contest.
Es erklärt auch, wie Bandinformationen, Prioritäten, Erreichbarkeit und
weitere Betriebshilfen hergeleitet werden und an welchen Stellen die
verfügbaren Daten keine eindeutige Aussage erlauben.
</p>
<div class="actions">
<a class="button" href="/manual/de/installation/">Installation</a>
<a class="button secondary" href="/manual/de/konfiguration/">Konfiguration</a>
<a class="button ghost" href="/manual/de/funktionen/">Funktionen</a>
</div>
</section>
<section class="section">
<div class="section-heading">
<p class="eyebrow">Einstieg nach Aufgabe</p>
<h2>Wo solltest du anfangen?</h2>
<p>
Die Kapitel können einzeln verwendet werden. Bei einer neuen Installation
ist die folgende Reihenfolge jedoch meist sinnvoller, als direkt in einer
Detailfunktion zu beginnen.
</p>
</div>
<div class="grid">
<article class="card">
<h3>KST4Contest neu installieren</h3>
<p>
Wähle den passenden Build, installiere die Anwendung und prüfe, ob sie
auf dem vorgesehenen Contest-Rechner korrekt startet.
</p>
<div class="actions">
<a class="button" href="/download/">Build auswählen</a>
<a class="button secondary" href="/manual/de/installation/">Installation öffnen</a>
</div>
</article>
<article class="card">
<h3>Die eigene Station einrichten</h3>
<p>
Trage Rufzeichen, Locator, verwendete Bänder und Chatkategorien ein.
Richte anschließend nur die Schnittstellen ein, die im Stationsaufbau
tatsächlich verwendet werden.
</p>
<div class="actions">
<a class="button secondary" href="/manual/de/konfiguration/">Konfiguration öffnen</a>
<a class="button ghost" href="/manual/de/log-synchronisation/">Log-Synchronisation</a>
</div>
</article>
<article class="card">
<h3>Die Anzeigen richtig einordnen</h3>
<p>
Prioritäten, Bandinformationen, AP-Bewertungen und Erreichbarkeit werden
aus mehreren Quellen abgeleitet. Die entsprechenden Kapitel erklären,
welche Informationen dafür verwendet werden und wo die Grenzen liegen.
</p>
<div class="actions">
<a class="button secondary" href="/manual/de/funktionen/">Funktionen öffnen</a>
<a class="button ghost" href="/manual/de/benutzeroberflaeche/">Benutzeroberfläche</a>
</div>
</article>
</div>
</section>
<section class="section">
<div class="section-heading">
<p class="eyebrow">Alle Kapitel</p>
<h2>Vollständiges deutsches Handbuch</h2>
<p>
Die Liste wird automatisch aus den Markdown-Dateien im Verzeichnis
<code>github_docs</code> erzeugt. Änderungen am zentralen Handbuch werden
dadurch auch in die Online-Dokumentation übernommen.
</p>
</div>
<div class="grid">
{% for manual in collections.manualPages %}
{% if manual.lang == "de" %}
<div class="card">
<h3><a href="/manual/de/{{ manual.slug }}/">{{ manual.title }}</a></h3>
<article class="card">
<h3>
<a href="/manual/de/{{ manual.slug }}/">{{ manual.title }}</a>
</h3>
{% if manual.summary %}
<p>{{ manual.summary }}</p>
{% endif %}
</div>
<p>
<a href="/manual/de/{{ manual.slug }}/">Kapitel öffnen →</a>
</p>
</article>
{% endif %}
{% endfor %}
</div>
+89 -6
View File
@@ -1,24 +1,107 @@
---
layout: base.njk
title: KST4Contest English Manual
description: English user manual for KST4Contest.
lang: en
title: KST4Contest English Manual
description: Technical user manual covering installation, configuration, ON4KST operation, AirScout, log synchronisation and the other functions of KST4Contest.
---
<section class="hero">
<p class="eyebrow">Documentation</p>
<h1>English Manual</h1>
<p>The manual is maintained centrally in GitHub and published as Wiki, PDF and online documentation.</p>
<p>
This manual describes more than the controls of KST4Contest. It also
explains how band information, priorities, reachability and other operating
aids are derived, and where the available data does not support an
unambiguous result.
</p>
<div class="actions">
<a class="button" href="/manual/en/installation/">Installation</a>
<a class="button secondary" href="/manual/en/configuration/">Configuration</a>
<a class="button ghost" href="/manual/en/features/">Functions</a>
</div>
</section>
<section class="section">
<div class="section-heading">
<p class="eyebrow">Start with the task</p>
<h2>Where should you begin?</h2>
<p>
Each chapter can be used separately. For a new installation, however,
the following order is usually more useful than starting with an isolated
detail.
</p>
</div>
<div class="grid">
<article class="card">
<h3>Install KST4Contest</h3>
<p>
Select the appropriate build, install the application and verify that it
starts correctly on the computer intended for contest operation.
</p>
<div class="actions">
<a class="button" href="/download/">Select a build</a>
<a class="button secondary" href="/manual/en/installation/">Open installation</a>
</div>
</article>
<article class="card">
<h3>Configure the station</h3>
<p>
Enter the callsign, locator, available bands and chat categories. Then
configure only the interfaces that are actually part of the station
setup.
</p>
<div class="actions">
<a class="button secondary" href="/manual/en/configuration/">Open configuration</a>
<a class="button ghost" href="/manual/en/log-sync/">Log synchronisation</a>
</div>
</article>
<article class="card">
<h3>Interpret the displayed information</h3>
<p>
Priorities, band information, AP assessments and reachability are
derived from several sources. The corresponding chapters explain which
information is used and where its limitations begin.
</p>
<div class="actions">
<a class="button secondary" href="/manual/en/features/">Open functions</a>
<a class="button ghost" href="/manual/en/user-interface/">User interface</a>
</div>
</article>
</div>
</section>
<section class="section">
<div class="section-heading">
<p class="eyebrow">All chapters</p>
<h2>Complete English manual</h2>
<p>
This list is generated automatically from the Markdown files in
<code>github_docs</code>. Changes to the central manual are therefore also
included in the online documentation.
</p>
</div>
<div class="grid">
{% for manual in collections.manualPages %}
{% if manual.lang == "en" %}
<div class="card">
<h3><a href="/manual/en/{{ manual.slug }}/">{{ manual.title }}</a></h3>
<article class="card">
<h3>
<a href="/manual/en/{{ manual.slug }}/">{{ manual.title }}</a>
</h3>
{% if manual.summary %}
<p>{{ manual.summary }}</p>
{% endif %}
</div>
<p>
<a href="/manual/en/{{ manual.slug }}/">Open chapter →</a>
</p>
</article>
{% endif %}
{% endfor %}
</div>
+76 -4
View File
@@ -1,18 +1,90 @@
---
layout: base.njk
title: KST4Contest Manual
description: Online manual for KST4Contest, the contest-optimized ON4KST chat client.
description: Technical user manual for KST4Contest, covering installation, station setup, ON4KST operation, AirScout, logger interfaces, path analysis and known limitations.
---
<section class="hero">
<span class="eyebrow">Documentation</span>
<h1>KST4Contest Manual</h1>
<p>
User documentation for installation, configuration, features,
AirScout integration, log synchronization and contest workflow.
The manual describes the controls and interfaces of KST4Contest as well as
the reasoning behind functions that derive information from chat messages,
station data or external programs. Where a result depends on incomplete
information, the corresponding limitations are described as well.
</p>
<div class="actions">
<a class="button" href="/manual/en/">English Manual</a>
<a class="button" href="/manual/en/">English manual</a>
<a class="button secondary" href="/manual/de/">Deutsches Handbuch</a>
<a class="button ghost" href="/download/">Download KST4Contest</a>
</div>
</section>
<section class="section">
<div class="section-heading">
<span class="eyebrow">Where to start</span>
<h2>Select the section that matches your current task</h2>
</div>
<div class="grid">
<article class="card">
<h3>Install KST4Contest</h3>
<p>
Select a Stable, Beta or Nightly build and install the application on
Windows, Linux or macOS.
</p>
<div class="actions">
<a class="button" href="/download/">Downloads</a>
<a class="button secondary" href="/manual/en/installation/">English instructions</a>
<a class="button ghost" href="/manual/de/installation/">Deutsche Anleitung</a>
</div>
</article>
<article class="card">
<h3>Configure a station</h3>
<p>
Set the callsign, locator, available bands, chat categories and the
interfaces used in the station setup.
</p>
<div class="actions">
<a class="button secondary" href="/manual/en/configuration/">English configuration</a>
<a class="button ghost" href="/manual/de/konfiguration/">Deutsche Konfiguration</a>
</div>
</article>
<article class="card">
<h3>Understand functions and limitations</h3>
<p>
Read how KST4Contest derives band information, priorities, reachability
and other operating aids, and where manual verification is still
required.
</p>
<div class="actions">
<a class="button secondary" href="/manual/en/features/">English functions</a>
<a class="button ghost" href="/manual/de/funktionen/">Deutsche Funktionen</a>
</div>
</article>
</div>
</section>
<section class="section">
<div class="cta-panel">
<div>
<span class="eyebrow">Choosing a build</span>
<h2>Stable for operation, Beta or Nightly for testing</h2>
<p>
The Stable build is normally the appropriate choice for contest
operation. Beta and Nightly builds are useful when a specific correction
or new function needs to be tested. Test them before the contest rather
than during its first minutes.
</p>
</div>
<div class="actions">
<a class="button" href="/download/">Open downloads</a>
<a class="button secondary" href="/roadmap/">View roadmap</a>
</div>
</div>
</section>
+93
View File
@@ -0,0 +1,93 @@
const assert = require("node:assert/strict");
const test = require("node:test");
const generateVersionInfo =
require("../src/_data/versionInfo");
const {
validateVersionInfo
} = require("../scripts/validate-version-info");
const VALID_XML =
`<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<praktiKST>
<latestVersion>
<versionNumber>1.411</versionNumber>
<semanticVersion>1.41.1</semanticVersion>
<adminMessage></adminMessage>
<majorChanges>Hotfix</majorChanges>
<latestVersionPathOnWebserver>https://github.com/praktimarc/kst4contest/releases/tag/v1.41.1</latestVersionPathOnWebserver>
</latestVersion>
<needUpdateSinceLastVersion>
<filename>nothing</filename>
</needUpdateSinceLastVersion>
<changeLog>
<changedVersionNumber>1.41.1</changedVersionNumber>
<date>2026-07-08</date>
<description>Hotfix</description>
<added></added>
<changed></changed>
<fixed>Text input handling</fixed>
<removed></removed>
</changeLog>
</praktiKST>`;
test("accepts a complete update feed", () => {
const result =
validateVersionInfo(VALID_XML, "v1.41.1");
assert.equal(result.semanticVersion, "1.41.1");
assert.equal(result.changeLogEntries, 1);
});
test("rejects the former empty fallback", () => {
assert.throws(
() =>
validateVersionInfo(
'<?xml version="1.0" '
+ 'encoding="UTF-8"?>'
+ "<praktiKST></praktiKST>"
),
/empty or implausibly small/
);
});
test(
"rejects a feed which does not contain "
+ "the expected Stable release",
() => {
assert.throws(
() =>
validateVersionInfo(
VALID_XML,
"v1.42.0"
),
/does not match expected release/
);
}
);
test(
"aborts generation when GitHub rejects "
+ "the API request",
async () => {
const originalFetch = global.fetch;
global.fetch = async () => ({
ok: false,
status: 401,
headers: {
get: () => null
}
});
try {
await assert.rejects(
generateVersionInfo(),
/website build has been aborted.*HTTP 401/i
);
} finally {
global.fetch = originalFetch;
}
}
);