Author SHA1 Message Date
Marc Froehlich b00e4c1e3d fixed worked-flag in the qso-of-the-other-table 2026-08-07 23:43:04 +02:00
Marc Froehlich b3ca684f04 updated website for sked and timeline features 2026-08-07 23:38:13 +02:00
Marc Froehlich 1de9673d12 uploaded 2 manual pictures for sked and timeline 2026-08-07 23:34:57 +02:00
Marc Froehlich c119f28b30 Uploaded sked, timeline, priority candidates and wintest connection manuals 2026-08-07 23:13:40 +02:00
Marc Froehlich 6a7f07c62e fix(wintest): replace unreliable band-limited AUTO sked mode detection with explicit SSB/CW selection and show exact KST callsigns in the timeline and fixed (#50 ensured Filter-Reset) 2026-08-07 22:56:24 +02:00
Marc Froehlich 4f574ebec6 fix(wintest): add band-aware sked QRG resolution, preserve portable callsigns, strip KST suffixes and correct ADDSKED timestamps 2026-08-07 22:43:17 +02:00
Marc Froehlich 7ce31e110b fix(wintest): add band-aware sked QRG resolution, preserve portable callsigns, strip KST suffixes and correct ADDSKED timestamps 2026-08-07 22:28:51 +02:00
Marc Froehlich 92804a622a Corrected typo error in MessagebusmanagementThread. Solves (#48) 2026-08-07 22:08:19 +02:00
Marc Froehlich 8bd5d8877d Add persistent map analysis toggle and improve compact layout for smaller screens. Solves (#69) 2026-08-06 01:52:59 +02:00
Marc Froehlich 97a93f726b Added en-manual for priority score and preferences + website feature text changed 2026-08-06 00:53:17 +02:00
Marc Froehlich c682ecf3f9 Changed website manual navigation 2026-08-06 00:46:00 +02:00
Marc Froehlich 259d0a4916 added priority score manual 2026-08-06 00:42:44 +02:00
Marc Froehlich 6d65bc365c fixed scoreservice. Not-QRV stations and such which dont provide needed bands now never could appear at the prirotity list 2026-08-06 00:26:29 +02:00
Marc Froehlich 084923366f fix(chat): grouped calculation of priority score for equal raw callsigns with different suffixes (also fixes #73) 2026-08-06 00:18:36 +02:00
Marc Froehlich eb38268be5 fix(chat): separate active members by full callsign and category 2026-08-06 00:01:29 +02:00
Marc Froehlich 36d2bd512d updated english manuals for changes from 1.40 due to 1.42 2026-08-05 23:20:11 +02:00
Marc Froehlich ffe7343671 inserted screenshots for manual pages for wkd status infos, band settings, functions and settings 2026-08-05 22:58:34 +02:00
Marc Froehlich bdd10ee00b Created manual pages for wkd status infos, band settings, functions and settings 2026-08-05 01:55:10 +02:00
Marc Froehlich 6092ff882a added project Band enum from Win-Test band IDs 2026-08-05 01:18:41 +02:00
Rsclub2_2 e37cda8ff2 Add 50/70 MHz band support (table, NOT-QRV, station setup, loggers)
Issue #68

Adds Band.B_50/B_70 and wires them through the same band-opportunity
machinery as the other bands: X/a/B+/o table columns and filter button
in the User table and the Workedstn database table, NOT-QRV checkboxes
and propagation across callsign variants, "My station uses 6m/4m band"
toggles, station-name detection ("50", "6M", "70MHZ", "4M" - without
stealing the existing bare "70"/"6" cm-band shorthand), Win-Test sked
band IDs (10/50MHz, 11/70MHz), and UCX-logger worked-band recognition.

Persists worked50/70 and notQRV50/70 via an additive SQLite migration
(same ensureColumnExists pattern as the earlier v1.1->v1.2 migration),
verified against a real database file.

ReachabilityService.resolveAutoBand() now also falls back to 50 MHz
(then 70 MHz) for stations in the "50/70 MHz" chat category, mirroring
the existing Microwave-category fallback to 23cm.

Assisted by Claude Sonnet 5 <noreply@anthropic.com>
2026-08-04 21:10:15 +02:00
Rsclub2_2 fdec5220d1 Unify band-opportunity logic and add B+/a/o status to the station table
Issue #70, #66, #65

Introduces a shared BandOpportunityResolver so the station table's band
columns, the New bands filter, the band-upgrade hint, the priority
score, the map markers and the automatic reachability band selection
all derive band availability the same way: recent QRG detections (30
min window) plus station-name hints, evaluated across every active
callsignRaw variant, with manual NOT-QRV always taking precedence.

The per-band table cells now distinguish:
- X: worked on this band
- a: band available, call not worked on any band yet
- B+: band available, call already worked on another band
- o: grid square already worked on this band (any station) - combines
  with the others, e.g. "ao" or "B+o"

Both "a" and "o" can be toggled off in the GUI settings tab.

Assisted by Claude Sonnet 5 <noreply@anthropic.com>
2026-08-04 21:00:23 +02:00
Rsclub2_2 35f790f06b Fix stale Beta tab showing a superseded prerelease
GitHub never clears the prerelease flag once a beta ships as stable,
so the latest prerelease can be older than the latest stable release.
Compare publish dates and fall back to the empty state when stable is
newer.

Assisted by Claude Sonnet 5 <noreply@anthropic.com>
2026-08-04 20:49:06 +02:00
Rsclub2_2 c04117ad0a added Beta and Nightly Download Links to website using nightly.link 2026-08-03 22:31:14 +02:00
Marc Froehlich c7d1dfbe92 Refactored QRG recognition (added some band context to increase the quality of the values + changed cluster fallback-band-value to dropdown switch + normalizing qrg values) 2026-08-03 01:09:32 +02:00
Marc Froehlich e9f09b764d Refactored QRG recognition (added some band context to increase the quality of the values + changed cluster fallback-band-value to dropdown switch + normalizing qrg values) 2026-08-03 01:09:25 +02:00
Marc Froehlich b432129798 Added contactreplace packets for broadcast whole log - function of DXLog.net to the ucxlog packet listener 2026-07-28 19:30:26 +02:00
Marc Froehlich 344ca547fd Changed sked opportunity highlighting mechanism to more precision, updated the manual 2026-07-26 23:56:32 +02:00
Marc Froehlich 182de0526b Changed ui, used flowpanes to make center slider compatible to smaller screens. URLs are now clickable. Tooltips are shown in case of too small table drawings. Added documentation in the gethub manual. 2026-07-26 18:10:39 +02:00
Marc Froehlich 333063f350 Changed Autoanswer implementation (cooldown timer, message routing) and its documentation 2026-07-26 11:04:47 +02:00
Marc Froehlich ee974bbd73 Fixed beacon implementation, pstrotator settings, Variable handling, Shortcut and snipped preferences ui, beacon handling, AS Settings and all fitting manual texts 2026-07-26 09:49:50 +02:00
69 changed files with 7508 additions and 2331 deletions
Binary file not shown.

After

Width:  |  Height:  |  Size: 63 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 52 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 82 KiB

After

Width:  |  Height:  |  Size: 84 KiB

+115 -14
View File
@@ -26,17 +26,38 @@ Die zentrale Tabelle aller aktuell aktiven Chat-Nutzer. Spalten (je nach Konfigu
| Spalte | Inhalt |
|---|---|
| Call | Rufzeichen der Station |
| Name | Name aus dem Chat-Namenfeld |
| Loc | Maidenhead-Locator |
| Callsign | Rufzeichen der Station |
| Name | Name beziehungsweise Zusatzinformationen aus dem Chat-Namensfeld |
| QRA | Maidenhead-Locator |
| QRB | Entfernung in km |
| QTF | Richtung in Grad |
| QRG | Automatisch erkannte Frequenz |
| AP | AirScout-Flugzeugdaten (wenn aktiv) |
| Band-Farben | Worked/NOT-QRV-Status pro Band |
| QRG | Zuletzt aus einer Chat-Nachricht erkannte Frequenz |
| Tropo | Ergebnis der bandbezogenen Tropo- beziehungsweise Streckenbewertung |
| Score | Aktueller, numerisch sortierbarer Prioritätswert des normalisierten Basisrufzeichens |
| Act | Minuten seit der letzten Aktivität |
| AP | AirScout-Flugzeugdaten, sofern aktiviert |
| worked | Bandbezogener Worked-, Bandmöglichkeits- und Großfeldstatus sowie `wkdany` |
| NOT QRV @ | Bänder, auf denen die Station manuell als nicht QRV markiert wurde |
| Category | Chat-Kategorie des Eintrags |
Die QRG-Spalte zeigt die zuletzt für eine Station erkannte Frequenz. Fehlende Nullen werden für die Anzeige ergänzt, sodass beispielsweise `144.21` als `144.210` erscheint. Erkennt KST4Contest nacheinander Frequenzen auf mehreren Bändern, zeigt die Spalte den letzten Treffer; die internen Bandinformationen können trotzdem mehrere aktuelle Bänder der Station enthalten.
Relative Angaben werden zunächst mit einem höchstens 30 Minuten alten Bandkontext desselben Absenders kombiniert. Nur wenn dieser fehlt, verwendet KST4Contest das globale Fallback-Band. Erkennungsregeln, Beispiele und Grenzen: [QRG-Erkennung](de-Funktionen#qrg-erkennung).
### Worked-, Band- und Großfeldstatus
Die Unterspalten unter **worked** sind kompakt, weil bei mehreren aktivierten Bändern kaum Platz für ausgeschriebene Zustände bleibt. `X` kennzeichnet ein auf diesem Band gearbeitetes Rufzeichen. `a` und `B+` weisen auf ein angebotenes, noch nicht gearbeitetes Band hin. Ein angehängtes `o` bedeutet, dass das vierstellige Großfeld auf diesem Band bereits gearbeitet wurde.
Die Unterspalte **wkdany** ist bandunabhängig: `x` steht für ein bereits gearbeitetes Rufzeichen, `o` für ein auf irgendeinem Band gearbeitetes Großfeld und `xo` für beides.
Jede Statuszelle besitzt einen Tooltip mit der Legende und dem für die betreffende Station ermittelten Zustand. Die vollständige Herleitung einschließlich NOT-QRV-Vorrang: [Gearbeitete Rufzeichen, neue Bänder und neue Großfelder](de-Funktionen#gearbeitete-rufzeichen-neue-bänder-und-neue-großfelder).
![Bandbezogener Worked-Status und Worked-Großfelder](worked_band_status.png)
**Sortierung**: Klick auf Spaltenköpfe. QRB-Sortierung arbeitet numerisch (ab v1.22 korrigiert).
Ein grün und fett dargestelltes Rufzeichen kennzeichnet eine aus einer gerichteten Nachricht hergeleitete Richtungsgelegenheit. Die Markierung bezieht sich auf den Absender der Nachricht und bleibt höchstens fünf Minuten sichtbar. Herleitung und Grenzen: [Richtungsgelegenheiten aus gerichteten Nachrichten](de-Funktionen#richtungsgelegenheiten-aus-gerichteten-nachrichten).
### Sendfeld
Texteingabe für ausgehende Nachrichten. Nach Klick auf ein Rufzeichen in der Benutzerliste erhält das Sendfeld automatisch den Fokus sofort tippen ohne Doppelklick (ab v1.22).
@@ -51,28 +72,108 @@ Eingabefeld für die aktuelle Antennenrichtung. Wird für die geplante `MYQTF`-V
---
## Nachrichtentabellen
KST4Contest zeigt Nachrichtentexte bewusst einzeilig an. So bleiben auch bei hohem Chat-Aufkommen viele Einträge gleichzeitig sichtbar. Der Nachteil liegt auf der Hand: Bei einer schmalen **Message**-Spalte passt nicht jede Nachricht vollständig in die Zeile.
Ist ein Nachrichtentext breiter als die sichtbare Zelle, zeigt KST4Contest den vollständigen Inhalt als Tooltip an. Dazu die Maus kurz über die betreffende **Message**-Zelle halten. Passt der Text vollständig in die Spalte, wird kein zusätzlicher Volltext-Tooltip eingeblendet.
Webadressen mit `http://`, `https://` oder dem Präfix `www.` werden innerhalb des Nachrichtentextes als Links dargestellt. Ein Klick öffnet die Adresse im Standardbrowser des Betriebssystems. Andere Protokolle werden nicht als Link behandelt.
![Abgeschnittener Nachrichtentext mit Volltext-Tooltip und Link](message_tooltip_and_link.png)
Damit muss der Divider nicht allein deshalb verschoben werden, um eine einzelne längere Nachricht zu lesen. Für einen dauerhaft breiteren Nachrichtenbereich kann er selbstverständlich weiterhin angepasst werden.
---
## Filter
Die Filter-Leiste (ab v1.21 als Flowpane für kleine Bildschirme):
Die Filterleiste befindet sich oberhalb der Chatmember-Tabelle. Sie ist in mehrere logisch zusammengehörige Bereiche gegliedert:
- **Show only QTF**: Richtungsfilter aktivieren (Buttons N/NE/E/… oder Grad-Eingabe)
- **Show only QRB [km] <=**: Entfernungsfilter aktivieren (Toggle-Button)
- **Hide Worked [Band]**: Gearbeitete Stationen pro Band ausblenden (je ein Toggle pro Band)
- **Hide NOT-QRV [Band]**: NOT-QRV-markierte Stationen pro Band ausblenden
- **Show only QTF** begrenzt die Liste auf eine gewählte Antennenrichtung.
- **Show only QRB [km] <=** setzt eine maximale Entfernung.
- **Find** sucht nach einem Rufzeichen.
- **wkd** blendet Rufzeichen aus, die bereits auf mindestens einem Band gearbeitet wurden.
- Die einzelnen Band-Schaltflächen blenden eine Station aus, wenn sie auf dem betreffenden Band bereits gearbeitet oder dort als NOT QRV markiert wurde. Angezeigt werden nur die für die eigene Station aktivierten Bänder.
- **Only new grids** zeigt ausschließlich Stationen aus vierstelligen Großfeldern, die auf noch keinem Band gearbeitet wurden.
- **Grid color** ist kein Filter. Die Funktion markiert das QRA-Feld bereits gearbeiteter Großfelder, ohne Stationen auszublenden.
- **New bands** zeigt Stationen mit mindestens einer erkannten, an der eigenen Station aktivierten und noch nicht gearbeiteten Bandmöglichkeit. NOT-QRV-Markierungen haben Vorrang.
- **Reachability**, **Tropo >=0dB** und **AS next 5m** schränken die Liste anhand der gewählten Strecken- beziehungsweise AirScout-Bedingungen ein.
Die Filterleiste besitzt keine feste Breite. QTF sowie die Worked- und Reachability-Filter nutzen zunächst den gesamten Platz ihrer jeweiligen Zeile. Wird der horizontale Divider nach rechts verschoben und die Chatmember-Ansicht dadurch schmaler, wechseln die Controls erst dann in die nächste Zeile, wenn ihre tatsächlich benötigte Breite nicht mehr zur Verfügung steht.
![Umgebrochene Filterleiste bei schmaler Chatmember-Ansicht](filter_bar_wrapped.png)
Im Klartext: Die Filter bestimmen weiterhin den Inhalt der Tabelle, aber nicht mehr die Mindestbreite der gesamten rechten Programmseite. In der normalen Ansicht bleibt die Leiste kompakt. Erst bei einer tatsächlich schmalen Ansicht benötigt sie mehr Höhe. Der Divider kann anschließend wieder nach links verschoben werden; die Controls ordnen sich unmittelbar neu an.
---
---
## Stationsinfo-Panel (Further Info)
Rechts unten: Zeigt alle Nachrichten einer ausgewählten Station (CQ-Nachrichten und PMs in einem Panel). Ein Nachrichtenfilter lässt sich über den Standard-Filter in den Preferences vorbelegen.
Rechts unten werden die Nachrichten der ausgewählten Station zusammengeführt. Dazu gehören öffentliche Nachrichten, Privatnachrichten an die eigene Station und soweit im Chat sichtbar Privatnachrichten an andere Stationen.
Hier können auch **Sked-Erinnerungen** aktiviert werden.
Der im Panel gewählte Filter bestimmt, welche dieser Nachrichten angezeigt werden. Unter **Settings → GUI** lässt sich festlegen, welcher Filter beim Öffnen einer Stationsinformation vorausgewählt ist:
- alle Nachrichten,
- Privatnachrichten an die eigene Station,
- Privatnachrichten an andere Stationen oder
- öffentliche Nachrichten.
Die Einstellung verändert nur die Darstellung im Stationsinfo-Panel. Nachrichten werden dadurch weder verworfen noch aus den übrigen Nachrichtentabellen entfernt. Der Filter kann im Panel jederzeit für die aktuell betrachtete Station gewechselt werden.
Im unteren Bereich können für die ausgewählte Station bandbezogene **Not QRV**-Markierungen gesetzt werden. Sichtbar sind die Bänder, die in den Stationseinstellungen für die eigene Station aktiviert wurden. **tag not qrv all** setzt beziehungsweise entfernt die Markierung für alle unterstützten Bänder gemeinsam, einschließlich momentan nicht eingeblendeter Bänder.
Die Änderung wirkt sofort auf die Spalte **NOT QRV @**, die Bandmöglichkeiten und die zugehörigen Filter. Sie wird in der internen Datenbank gespeichert und nach einem Neustart wiederhergestellt.
![Bandbezogene NOT-QRV-Markierungen im Further-Info-Bereich](not_qrv_controls.png)
Im selben Bereich wird der aktuelle **Priority score** der ausgewählten Station angezeigt.
Mit **Sked fail** lässt sich ein fehlgeschlagener Versuch markieren. Der Score des normalisierten Basisrufzeichens wird dadurch stark reduziert. **Reset fail** entfernt diese Markierung wieder. Die Markierung gilt für alle aktiven Suffix- und Kategorievarianten der Station und bleibt innerhalb der laufenden Programmsitzung erhalten.
Darunter befinden sich die Bedienelemente zum Anlegen eines Skeds:
| Bedienelement | Bedeutung |
|---|---|
| **Sked in** | Zeit bis zum Sked |
| **Band** | vereinbartes Band aus den eigenen aktivierten Bändern |
| **Mode** | `SSB` oder `CW` für eine mögliche Win-Test-Übergabe |
| **Create sked** | internen Sked anlegen |
| **Remind-PM in** | automatische Reminder-PMs aktivieren |
| **2+1**, **5+2+1**, **10+5+2+1** | Zeitpunkte der Reminder-PMs vor dem Termin |
![Sked-Steuerung im Further-Info-Bereich](sked_controls.png)
Das vorgeschlagene Band wird aus aktuellen QRG- und Namensinformationen der Station hergeleitet. Vor dem Anlegen kann es ausdrücklich geändert werden. Die Mode-Auswahl betrifft nur die Übergabe an Win-Test; der interne Sked und die Reminder-PMs funktionieren unabhängig davon.
**Create sked** legt den Termin immer zuerst in KST4Contest an. Ist der Win-Test-Netzwerk-Listener aktiv, wird anschließend zusätzlich eine Übergabe an Win-Test versucht. Kann keine zum ausgewählten Band passende QRG ermittelt werden oder ist Win-Test nicht erreichbar, bleiben der interne Sked, seine Priorisierung und gegebenenfalls angelegte Reminder erhalten.
Die vollständige Herleitung und die Grenzen der Funktion sind unter [Skeds und Sked-Erinnerungen](de-Funktionen#skeds-und-sked-erinnerungen) beschrieben.
---
## Prioritätsliste
Zeigt die vom Score-Service berechneten Top-Kandidaten. Aktualisiert sich automatisch im Hintergrund basierend auf Richtung, Entfernung und AP-Verfügbarkeit.
Die kompakte Prioritätsleiste befindet sich rechts zwischen Benutzerliste und Further-Info-Bereich. Sie zeigt die beiden derzeit höchstbewerteten Kandidaten unmittelbar im Hauptfenster:
```text
Priority: 1 RUFZEICHEN SCORE 2 RUFZEICHEN SCORE more
```
Ein Klick auf einen der beiden Kandidaten wählt den dazugehörigen aktiven Chatmember aus. Dabei werden das vollständige Rufzeichen einschließlich Suffix und die zugehörige Chat-Kategorie verwendet.
Die Schaltfläche **more** öffnet ein separates Fenster mit bis zu 15 Kandidaten. Die Liste ist nach absteigendem Score sortiert. Ein Doppelklick wählt den betreffenden Kandidaten aus und schließt das Fenster.
![Priority Score, kompakte Kandidatenliste und Further-Info-Steuerung](priority_score_overview.png)
Stationen mit einem Score von `0` werden nicht in die Prioritätsliste aufgenommen. In der Benutzerliste bleiben sie sichtbar, sodass der Ausschluss nachvollzogen und beispielsweise durch eine geänderte NOT-QRV-Markierung korrigiert werden kann.
Der Score wird für das normalisierte Basisrufzeichen berechnet. Mehrere aktive Varianten wie `9A0BB-2` und `9A0BB-70` können daher in der Benutzerliste denselben Wert anzeigen. Die Chatmember bleiben trotzdem getrennte Nachrichtenziele.
Neue Nachrichten, AirScout-Daten, Skeds und Statusänderungen lösen eine Neuberechnung aus. Zusätzlich erfolgt eine regelmäßige Aktualisierung im Hintergrund. Eine kurzzeitig noch nicht angepasste Reihenfolge ist deshalb kein Fehler.
Herleitung und Grenzen: [Prioritätsscore und Prioritätsliste](de-Funktionen#prioritätsscore-und-prioritätsliste-ab-v140).
---
+6
View File
@@ -8,6 +8,12 @@ Versionsverlauf von KST4Contest / PraktiKST.
letzter Changelog bitte aus GitHub entnehmen. Der bisherige Changelog
## 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.
## v1.41
**Stationskarte, Performance, Reaktionsfähiges UI**
+43 -21
View File
@@ -25,59 +25,79 @@ Im Klartext: Die Information muss nicht erst im Chat gefunden, gelesen, gemerkt
## Wie wird eine Richtungsgelegenheit hergeleitet?
Angenommen, Station A schreibt eine gerichtete Nachricht an Station B. KST4Contest geht in diesem Fall davon aus, dass Station A ihre Antenne zumindest ungefähr in Richtung von Station B ausgerichtet hat.
Angenommen, Station A schreibt eine gerichtete Nachricht an Station B. KST4Contest verwendet die Richtung von A zu B als Näherung für die aktuelle Antennenrichtung von Station A. Anschließend wird geprüft, ob die eigene Station aus Sicht von A innerhalb des angenommenen Antennenkorridors liegt.
Anschließend werden zwei Richtungen verglichen:
Dafür werden zwei Richtungen verglichen:
- die Richtung von Station A zu Station B,
- die Richtung von Station A zur eigenen Station.
Liegt die eigene Station innerhalb des konfigurierten Antennen-Öffnungswinkels und befindet sich Station A innerhalb des eingestellten maximalen QRB, wird die Situation als Richtungsgelegenheit behandelt.
Der in den Station Settings konfigurierte Antennen-Öffnungswinkel ist der vollständige Winkel. Für die Prüfung wird jeweils die Hälfte links und rechts der Richtung A → B angesetzt. Bei `70°` sind das somit `±35°`.
Da ON4KST keine Antennendaten der fremden Station überträgt, verwendet KST4Contest den Öffnungswinkel der eigenen Antenne zugleich als Näherung für Station A. Das ist keine Messung der tatsächlichen Antennenrichtung, sondern eine bewusst einfache geometrische Annahme.
Ein DX-Cluster-Spot wird nur erzeugt, wenn alle folgenden Bedingungen erfüllt sind:
1. Die Nachricht ist an eine konkrete andere Station gerichtet.
1. Eine gerichtete Nachricht wurde zwischen zwei anderen Stationen erkannt.
2. Für Absender und Empfänger sind gültige Locator bekannt.
3. Der Absender liegt innerhalb des konfigurierten maximalen QRB.
4. Die eigene Station liegt aus Sicht des Absenders innerhalb des konfigurierten Antennen-Öffnungswinkels.
5. Für den Absender ist eine verwertbare Frequenz bekannt.
3. Der Absender liegt innerhalb des konfigurierten maximalen QRB zur eigenen Station.
4. Die eigene Station liegt aus Sicht des Absenders innerhalb des angenommenen Antennenkorridors.
5. Für den Absender ist eine verwertbare Frequenz bekannt oder in der aktuellen Nachricht erkannt worden.
6. Der lokale DX-Cluster-Server ist aktiviert.
Das Verfahren ist bewusst eine geometrische Herleitung. Es beweist weder, dass die Gegenstation tatsächlich mit genau dieser Antennenrichtung arbeitet, noch ersetzt es eine Ausbreitungsberechnung. Es erkennt eine plausible Gelegenheit. Mehr sollte man aus einer Chat-Nachricht auch nicht herauslesen.
Treffen die Bedingungen zu, wird der Spot unmittelbar beim Verarbeiten der Nachricht erzeugt. Die parallel angezeigte grüne Richtungsmarkierung bleibt dagegen fünf Minuten sichtbar und kann durch spätere Nachrichten verlängert oder vorzeitig entfernt werden.
Das Verfahren berücksichtigt weder Gelände noch aktuelle Ausbreitungsbedingungen und beweist keine tatsächliche Antennenstellung. Es erkennt eine plausible Gelegenheit. Die ausführliche Herleitung und ein Zahlenbeispiel stehen unter [Richtungsgelegenheiten aus gerichteten Nachrichten](de-Funktionen#richtungsgelegenheiten-aus-gerichteten-nachrichten).
---
## Welche Frequenz wird verwendet?
Vollständige Frequenzangaben können direkt verarbeitet werden, beispielsweise:
Ein DX-Cluster-Spot benötigt eine eindeutige Frequenz. KST4Contest verwendet dafür dieselbe QRG-Erkennung wie die Benutzerliste und die übrigen bandbezogenen Funktionen.
Vollständige Frequenzen bestimmen ihr Band direkt:
```text
144.205
432.088
432,088
1296.338
10368.100
```
Im Chat werden jedoch häufig nur relative Angaben geschrieben:
Relative Angaben enthalten dagegen nur den Frequenzanteil innerhalb eines Bandes:
```text
205
.205
338
,205
qrg 205
freq is 205
on 205
205 MHz
```
In diesem Fall fehlt das Band. KST4Contest ergänzt deshalb das unter **Fallback band in MHz** konfigurierte Bandpräfix.
Eine nackte dreistellige Zahl wie `205` wird ohne Frequenzkontext nicht ausgewertet. Dasselbe gilt für `599`, `144` oder Formulierungen wie `worked 210 stations`. So verhindert KST4Contest, dass Signalrapporte, Bandnamen oder Zählwerte als scheinbar plausible QRG gespeichert und später an den Logger weitergegeben werden.
Bei einer relativen QRG wird das Band in dieser Reihenfolge bestimmt:
1. KST4Contest prüft, ob für denselben Absender innerhalb der letzten 30 Minuten bereits ein passender Bandkontext bekannt wurde.
2. Sind mehrere aktuelle Bänder bekannt, wird der zuletzt aktualisierte plausible Kontext verwendet.
3. Erst wenn kein geeigneter Stationskontext vorhanden ist, verwendet KST4Contest das unter **Fallback band for relative QRG detection** ausgewählte Band.
Beispiel:
```text
Fallback-Band: 144
Chat-Frequenz: .205
DX-Cluster-Frequenz: 144205.0 kHz
Globales Fallback: 144 MHz
Letzte vollständige QRG der Station: 432.088 MHz
Neue Chat-Angabe derselben Station: .100
Erkannte QRG: 432.100 MHz
DX-Cluster-Frequenz: 432100.0 kHz
```
Bei einem Einband-Contest ist diese Annahme normalerweise eindeutig. Bei gleichzeitigem Betrieb mehrerer Bänder kann sie falsch sein. Das Fallback-Band sollte deshalb zu dem Band passen, das in der betreffenden Chat-Kategorie überwiegend verwendet wird.
Ohne den aktuellen 432-MHz-Kontext würde dieselbe Angabe mit dem globalen Fallback zu `144.100 MHz` ergänzt.
Die weitergehende Frage, ob sich das Band künftig aus der konkreten Arbeitsfrequenz oder dem Stationskontext ableiten lässt, wird nach Abschluss des Manuals gesondert geprüft.
Die QRG-Erkennung läuft vor der Richtungs- und Spotprüfung. Nennt eine Station ihre Frequenz erstmals in der gerichteten Nachricht, die zugleich eine Richtungsgelegenheit auslöst, kann bereits der daraus erzeugte Spot diese Frequenz enthalten. War zuvor eine andere QRG der Station bekannt, wird sie durch die neu erkannte Angabe aktualisiert.
Das Fallback-Band ist eine globale Einstellung der QRG-Erkennung. Seine Wirkung ist nicht auf den DX-Cluster beschränkt. Konfiguration, unterstützte Bänder und weitere Folgen sind unter [Fallback-Band für relative QRG-Erkennung](de-Konfiguration#fallback-band-für-relative-qrg-erkennung) beschrieben.
---
@@ -91,7 +111,7 @@ Konfiguriere anschließend:
1. **Enable the local DX Cluster server …** aktivieren.
2. Einen freien **TCP port** eintragen. Standard ist `8000`.
3. Das passende **Fallback band in MHz** eintragen.
3. Unter **Fallback band for relative QRG detection** das passende Band auswählen.
4. Ein **Spotter callsign** festlegen.
Für das Spotter-Rufzeichen sollte nach Möglichkeit ein anderes Rufzeichen als das Contest-Rufzeichen verwendet werden. Einige Logger filtern Spots, die scheinbar von der eigenen Station stammen. Das Ergebnis wäre technisch korrekt erzeugt, aber in der Bandmap trotzdem unsichtbar eine besonders unproduktive Art von Erfolg.
@@ -185,7 +205,9 @@ KST4Contest sendet absichtlich nicht jede gefundene Frequenz an den Logger. Ande
### Der Spot erscheint auf dem falschen Band
Prüfe zuerst das konfigurierte **Fallback band in MHz**. Es wird nur benötigt, wenn im Chat keine vollständige Frequenz angegeben wurde.
Prüfe zuerst, welche Frequenzen für die betreffende Station innerhalb der letzten 30 Minuten erkannt wurden. Bei einer relativen Angabe hat dieser Stationskontext Vorrang vor dem globalen Fallback.
Ist kein aktueller Stationskontext vorhanden, prüfe die Auswahl unter **Fallback band for relative QRG detection**. Das Fallback wird nur benötigt, wenn sich das Band weder aus einer vollständigen Frequenz noch aus dem aktuellen Kontext des Absenders ergibt.
### Der Spot wird vom Logger ausgeblendet
+449 -69
View File
@@ -2,63 +2,209 @@
> 🇬🇧 [English version](en-Features) | 🇩🇪 Du liest gerade die deutsche Version
Übersicht aller Hauptfunktionen von KST4Contest.
Dieses Kapitel beschreibt die wichtigsten Funktionen von KST4Contest, ihre Herleitung und die Grenzen der daraus gewonnenen Informationen.
---
## Richtungsgelegenheiten aus gerichteten Nachrichten
## Sked-Richtungs-Hervorhebung
Im ON4KST-Chat ist sichtbar, welche Station eine Nachricht an welche andere Station richtet. Eine tatsächliche Antennenrichtung wird dabei nicht übertragen. Für den Contestbetrieb lässt sich aus einer solchen Nachricht trotzdem eine brauchbare Annahme ableiten: Wer einen Sked anfragt, beantwortet oder vorbereitet, richtet seine Antenne normalerweise zumindest ungefähr auf die angesprochene Station.
Eine der Kernfunktionen: Wenn eine Station ein Sked in die **eigene Richtung** sendet, wird sie in der Benutzerliste **grün und fett** hervorgehoben.
KST4Contest wertet deshalb gerichtete Nachrichten zwischen zwei anderen Stationen aus. Die Nachricht muss nicht ausdrücklich als Sked gekennzeichnet sein. Entscheidend sind der Absender, der Empfänger und deren Locator.
### Wie funktioniert das?
### Wie wird die Richtung hergeleitet?
Die Berechnung basiert auf folgender Logik:
Angenommen, Station A schreibt eine gerichtete Nachricht an Station B:
- Wenn Station A eine Sked-Anfrage an Station B sendet, wird angenommen, dass A ihre Antenne auf B ausrichtet.
- Wenn die daraus resultierende Richtung von A zur eigenen Station innerhalb des halben Öffnungswinkels der eigenen Antenne liegt, wird A hervorgehoben.
1. KST4Contest berechnet die Richtung von Station A zu Station B.
2. Diese Richtung wird als wahrscheinliche Antennenrichtung von Station A verwendet.
3. Anschließend wird die Richtung von Station A zur eigenen Station berechnet.
4. Die Winkeldifferenz wird mit der Hälfte des konfigurierten Antennen-Öffnungswinkels verglichen.
5. Zusätzlich muss Station A innerhalb des konfigurierten maximalen QRB liegen.
**Beispiel** (Öffnungswinkel 69°, Halbwinkel 34,5°):
Ein eingetragener Öffnungswinkel von `70°` ergibt damit einen angenommenen Korridor von jeweils `35°` links und rechts der Richtung von Station A zu Station B.
| Situation | Ergebnis für DO5AMF in JN49 |
| Beispiel | Ergebnis |
|---|---|
| Sked von F5FEN → DM5M | ✅ Hervorhebung (F5FEN zeigt Richtung DM5M, das liegt nahe JN49) |
| Sked von DM5M → F5FEN | ✅ Hervorhebung (DM5M antwortet in Richtung F5FEN) |
| F1DBN ist unbeteiligt | Keine Hervorhebung |
| DO5AMF/P (anderer Standort) | ❌ Keine Hervorhebung für Sked-Antwort |
| Richtung A → B: `120°`, Richtung A → eigene Station: `145°` | Winkeldifferenz `25°`: Richtungsgelegenheit erkannt |
| Richtung A → B: `120°`, Richtung A → eigene Station: `165°` | Winkeldifferenz `45°`: außerhalb des angenommenen Korridors |
| Locator von A oder B fehlt | Keine Richtungsberechnung möglich |
| A liegt außerhalb des maximalen QRB | Keine Richtungsgelegenheit |
Die Berechnung berücksichtigt keine topografischen Wegberechnungen das ist eine bewusste Vereinfachung. Möglicherweise wird das in einer späteren Version ergänzt.
### Was wird in der Benutzerliste angezeigt?
> Konfiguration: [Konfiguration Antennen-Öffnungswinkel](Konfiguration#antennen-öffnungswinkel-antenna-beamwidth)
Wird eine Richtungsgelegenheit erkannt, erscheint das Rufzeichen des Absenders in der Benutzerliste grün und fett. Im Evening-Modus wird dafür ein helleres Grün verwendet. Der Empfänger der Nachricht wird nicht allein deshalb markiert; eine Antwort in Gegenrichtung wird als eigene Nachricht und damit als neuer Fall berechnet.
![Erkannte Richtungsgelegenheit in der Benutzerliste](direction_opportunity_highlight.png)
Im Bild sendete DF0GEB eine gerichtete Nachricht an DN9APW und bekam eine Antwort. KST4Contest erkannte die Richtungsgelegenheit und markierte DN9APW in der Benutzerliste.
Zur Verdeutlichung ist die MAP eingeblendet. Ich stehe als Empfänger zwischen beiden Stationen und bekomme deswegen die Warnung.
Die Markierung bleibt fünf Minuten ab der letzten passenden Nachricht sichtbar. Eine weitere passende Nachricht derselben Station beginnt diesen Zeitraum erneut. Sendet die Station vorher eine gerichtete Nachricht, deren Richtung die Bedingungen nicht erfüllt, wird die Markierung unmittelbar entfernt.
Ist die einfache Soundausgabe aktiviert, gibt KST4Contest beim erstmaligen Erkennen der Richtungsgelegenheit zusätzlich einen kurzen Hinweis aus. Solange die Station bereits markiert ist, wird derselbe Hinweis nicht mit jeder weiteren passenden Nachricht wiederholt.
### Was bedeutet die Markierung und was nicht?
Die Berechnung ist eine geometrische Herleitung. Sie beweist nicht, dass Station A ihre Antenne tatsächlich auf Station B ausgerichtet hat. Ebenso wenig berücksichtigt sie Gelände, aktuelle Ausbreitungsbedingungen, die reale Antennencharakteristik der fremden Station oder deren Rotatorposition.
ON4KST liefert keinen individuellen Öffnungswinkel für die fremde Station. KST4Contest verwendet deshalb den für die eigene Antenne konfigurierten Wert auch als Näherung für Station A. Ein zu großer Wert erzeugt entsprechend mehr mögliche Richtungsgelegenheiten, ein zu kleiner Wert kann brauchbare Situationen übersehen.
Im Klartext: Die grüne Markierung ist ein begründeter Hinweis auf eine mögliche Gelegenheit. Sie ist weder eine Ausbreitungsvorhersage noch eine Garantie für ein QSO.
Konfiguration:
- [Antennen-Öffnungswinkel](de-Konfiguration#antennen-öffnungswinkel-antenna-beamwidth)
- [Standard-Maximum-QRB](de-Konfiguration#standard-maximum-qrb)
---
## Sked-Richtungs-Spots (Integrierter DX-Cluster)
## Weitergabe als DX-Cluster-Spot
Seit Version 1.23 kann KST4Contest erkannte Richtungsgelegenheiten als DX-Cluster-Spots an ein verbundenes Logprogramm weitergeben.
Seit Version 1.23 kann KST4Contest eine erkannte Richtungsgelegenheit an den DX-Cluster-Client eines Logprogramms weitergeben. Dafür muss der lokale DX-Cluster-Server aktiviert und für den Absender eine verwertbare Frequenz bekannt sein.
Aus einer gerichteten Chat-Nachricht wird zunächst die wahrscheinliche Antennenrichtung des Absenders hergeleitet. Liegt die eigene Station innerhalb des konfigurierten Öffnungswinkels und ist eine Frequenz bekannt, erscheint die Station als Spot in der Bandmap des Logprogramms.
Die Frequenz kann bereits aus einer früheren Nachricht stammen oder erstmals in der aktuell auslösenden Nachricht stehen. In beiden Fällen steht sie der Spot-Prüfung zur Verfügung. KST4Contest überträgt damit nicht jede im Chat gefundene QRG, sondern nur Frequenzen, die mit einer geometrisch passenden gerichteten Nachricht zusammenfallen.
KST4Contest überträgt damit nicht jede gefundene Frequenz, sondern nur Situationen, die für die eigene Station geometrisch plausibel sind.
Die Fünf-Minuten-Markierung und der DX-Cluster-Spot beruhen auf derselben Richtungsberechnung, haben aber einen unterschiedlichen Lebenszyklus: Die Markierung bleibt vorübergehend in der Benutzerliste sichtbar. Der Spot wird unmittelbar beim Verarbeiten der passenden Nachricht erzeugt.
Details: [Integrierter DX-Cluster-Server](de-DX-Cluster-Server).
Einrichtung, Frequenzbehandlung und Grenzen: [Integrierter DX-Cluster-Server](de-DX-Cluster-Server).
---
## QRG-Erkennung (QRG Reading)
## QRG-Erkennung
KST4Contest verarbeitet jede Chat-Nachricht und extrahiert automatisch **Frequenzangaben**. Diese werden in der Benutzerliste in der **QRG-Spalte** angezeigt.
Im ON4KST-Chat werden Frequenzen selten einheitlich geschrieben. Eine Station nennt beispielsweise zuerst `432.088`, später nur noch `.100` und in einer weiteren Nachricht `qrg 120`. Für einen Menschen ist der Zusammenhang meistens klar. Ein Programm muss dagegen unterscheiden, ob `120` eine Frequenz, eine Zeitangabe, eine Entfernung oder etwas völlig anderes bedeutet.
Erkannte Formate: `144.205`, `432.088`, `.205` (mit konfigurierter Bandannahme), etc.
KST4Contest wertet deshalb den Text jeder öffentlichen und gerichteten Chat-Nachricht aus. Eine erkannte QRG wird dem Absender zugeordnet und in der **QRG-Spalte** der Benutzerliste angezeigt. Die Spalte enthält die zuletzt erkannte Frequenz und stellt mindestens drei Nachkommastellen dar. Ein intern als `144.21` gespeicherter Wert erscheint damit als `144.210`.
**Nutzen**: Ohne nachzufragen kann man direkt auf die QRG einer Station schauen und entscheiden, ob eine Verbindung möglich ist.
### Welche Angaben werden erkannt?
| Schreibweise | Beispiel | Verarbeitung |
|---|---|---|
| Vollständige Frequenz | `144.210`, `432,088`, `10368.100` | Das Band ergibt sich direkt aus der Frequenz. |
| Relative Frequenz mit Punkt oder Komma | `.210`, `,088` | Das Band wird aus dem Stationskontext oder dem konfigurierten Fallback ergänzt. |
| Dreistellige Frequenz mit Textkontext | `qrg 210`, `freq is 210`, `on 210`, `210 MHz` | Die Zahl wird als relative Frequenz behandelt. |
| Dreistellige Zahl ohne Frequenzkontext | `210`, `599`, `144` | Die Zahl wird absichtlich nicht als QRG übernommen. |
Die letzte Einschränkung verhindert plausible, aber falsche Ergebnisse. Mit einem Fallback von `144 MHz` ließe sich ein Signalrapport `599` technisch problemlos zu `144.599 MHz` zusammensetzen. Das Ergebnis wäre formal gültig und fachlich trotzdem Unsinn.
### Wie wird das Band einer relativen QRG bestimmt?
KST4Contest verwendet folgende Reihenfolge:
1. Wurde für denselben Absender innerhalb der letzten 30 Minuten bereits eine passende vollständige Frequenz erkannt, verwendet KST4Contest deren Band.
2. Sind mehrere aktuelle Bänder bekannt, wird der zuletzt aktualisierte plausible Bandkontext verwendet.
3. Fehlt ein geeigneter Stationskontext, verwendet KST4Contest das unter **Fallback band for relative QRG detection** ausgewählte Band.
Beispiel: Das globale Fallback steht auf `144 MHz`. Eine Station nennt zunächst `432.088` und schreibt wenige Minuten später `.100`. KST4Contest ergänzt nicht das globale Fallback, sondern den aktuelleren Stationskontext. Das Ergebnis ist `432.100 MHz`. Schreibt eine andere Station ohne vorherige Bandinformation `.100`, wird daraus `144.100 MHz`.
Das Fallback-Band ist damit tatsächlich nur der letzte Ausweg. Es wird aus den von KST4Contest unterstützten Bandwerten ausgewählt und wirkt auf die gesamte QRG-Erkennung nicht nur auf den integrierten DX-Cluster.
### Wofür wird die erkannte QRG verwendet?
Die zuletzt erkannte Frequenz erscheint in der Benutzerliste. Der zugehörige Bandkontext kann außerdem in weitere Funktionen einfließen, beispielsweise in:
- die Erkennung aktiver Bänder einer Station,
- den Chatmember-Score und die Prioritätslisten,
- Band-Upgrade-Hinweise nach einem Logeintrag,
- die Frequenzwahl bei Skeds,
- einen DX-Cluster-Spot aus einer erkannten Richtungsgelegenheit.
Steht die QRG erstmals in der Nachricht, die zugleich eine Richtungsgelegenheit auslöst, wird sie vor der Richtungs- und Spotprüfung verarbeitet. Der daraus erzeugte Spot kann deshalb bereits die Frequenz dieser Nachricht verwenden.
Die Erkennung bleibt eine Textauswertung. KST4Contest kann nicht beweisen, dass die Station noch auf der genannten Frequenz arbeitet oder ob sich eine mehrdeutige Angabe auf einen anderen Zusammenhang bezieht. Genau deshalb werden nackte dreistellige Zahlen ohne Frequenzkontext nicht mehr übernommen.
Konfiguration und unterstützte Fallback-Bänder: [Fallback-Band für relative QRG-Erkennung](de-Konfiguration#fallback-band-für-relative-qrg-erkennung).
Verwendung in der Bandmap eines Logprogramms: [Integrierter DX-Cluster-Server](de-DX-Cluster-Server).
---
## Gearbeitete Rufzeichen, neue Bänder und neue Großfelder
## Worked-Markierung
KST4Contest unterscheidet drei Informationen, die im Contest ähnlich aussehen können, aber unterschiedliche Fragen beantworten:
Gearbeitete Stationen werden in der Benutzerliste visuell markiert pro Band. Grundlage ist die [Log-Synchronisation](de-Log-Synchronisation) via UDP oder Simplelogfile.
1. Wurde dieses Rufzeichen bereits gearbeitet?
2. Wurde dieses Rufzeichen auf einem bestimmten Band gearbeitet?
3. Wurde das vierstellige Maidenhead-Großfeld bereits gearbeitet möglicherweise mit einer anderen Station?
Diese Trennung ist notwendig. Ein bereits gearbeitetes Rufzeichen kann auf einem anderen Band weiterhin interessant sein. Umgekehrt kann eine noch nicht gearbeitete Station in einem Großfeld liegen, das bereits im Log steht.
### Worked-Informationen aus dem Log
Die [Log-Synchronisation](de-Log-Synchronisation) übernimmt neue QSOs aus dem Logprogramm. Welche Informationen dabei zur Verfügung stehen, hängt von der verwendeten Schnittstelle ab:
- Der dateibasierte Simplelogfile-Interpreter erkennt nur das Rufzeichen. Er kann deshalb lediglich den globalen Worked-Status setzen.
- Die QSO-UDP-Schnittstellen und der Win-Test-Netzwerk-Listener können zusätzlich das Band übernehmen.
- Enthält das Logpaket einen gültigen Locator, speichert KST4Contest außerdem das gearbeitete vierstellige Großfeld für dieses Band.
Fehlt eine Information im Logpaket, wird sie nicht geraten. Ein QSO ohne Locator erzeugt deshalb keinen Großfeld-Eintrag; ein Simplelogfile-Treffer erzeugt keine bandbezogene Worked-Markierung.
### Bedeutung der Bandspalten
Unter der gemeinsamen Spalte **worked** erscheinen nur die Bänder, die unter **Station → my station uses …** aktiviert wurden. Die Zellen verwenden bewusst kurze Kennzeichen:
| Anzeige | Bedeutung |
|---|---|
| `X` | Das Rufzeichen wurde auf diesem Band gearbeitet. |
| `a` | Die Station bietet dieses Band an, das Band ist noch nicht gearbeitet und das Rufzeichen wurde bisher auf keinem Band gearbeitet. |
| `B+` | Die Station bietet dieses Band an und das Band ist noch nicht gearbeitet. Das Rufzeichen wurde bereits auf einem anderen Band gearbeitet. Ist die getrennte `a`-Anzeige deaktiviert, wird auch ein vollständig neues Rufzeichen als `B+` dargestellt. |
| `o` | Das vierstellige Großfeld der Station wurde auf diesem Band bereits gearbeitet unabhängig vom Rufzeichen. |
| leer | Für dieses Band liegt keine passende Information vor. Das ist nicht gleichbedeutend mit „nicht QRV“. |
Das `o` ist eine unabhängige Zusatzinformation und kann deshalb mit den anderen Kennzeichen kombiniert werden. Möglich sind beispielsweise `Xo`, `ao` oder `B+o`. Ein einzelnes `o` bedeutet: Das Großfeld wurde auf diesem Band bereits gearbeitet, für das angezeigte Rufzeichen liegt aber weder eine Worked-Markierung noch eine aktuelle Bandmöglichkeit vor.
![Bandbezogener Worked-Status und Worked-Großfelder](worked_band_status.png)
### Wie entsteht eine Bandmöglichkeit?
KST4Contest zeigt `a` oder `B+` nur an, wenn sich eine noch offene gemeinsame Bandmöglichkeit herleiten lässt. Dafür werden folgende Informationen zusammengeführt:
1. die in den Stationseinstellungen aktivierten eigenen Bänder,
2. höchstens 30 Minuten alte QRG-Erkennungen der Gegenstation,
3. eindeutige Bandangaben im Namensfeld der Gegenstation,
4. die pro Band gespeicherten Worked-Markierungen und
5. manuell gesetzte NOT-QRV-Markierungen.
Aktive Chat-Einträge mit demselben normalisierten Rufzeichen werden gemeinsam ausgewertet. Das ist insbesondere bei mehreren Chat-Kategorien oder unterschiedlichen sichtbaren Rufzeichenvarianten wichtig. Eine eindeutige Bandangabe im Namensfeld bleibt dabei so lange nutzbar, wie der betreffende Chat-Eintrag aktiv ist; eine aus einer Nachricht erkannte QRG läuft nach 30 Minuten aus.
Anschließend werden nur die Bänder berücksichtigt, die an der eigenen Station aktiviert, für die Gegenstation bekannt und noch nicht gearbeitet sind. Ein manuelles NOT-QRV-Tag übersteuert die automatisch erkannten Hinweise. Die Chat-Kategorie allein reicht dagegen nicht als Nachweis, dass eine einzelne Station auf einem bestimmten Band QRV ist.
Die globale Worked-Markierung entscheidet nicht darüber, ob eine Bandmöglichkeit besteht. Sie unterscheidet in der Darstellung lediglich zwischen `a` und `B+`. Die eigentliche Bandprüfung arbeitet mit den bandbezogenen Worked-Informationen.
### Bedeutung von `wkdany`
Die Unterspalte **wkdany** fasst den globalen Rufzeichen- und Großfeldstatus zusammen:
| Anzeige | Bedeutung |
|---|---|
| leer | Weder das Rufzeichen noch das vierstellige Großfeld wurden gearbeitet. |
| `x` | Das Rufzeichen wurde auf mindestens einem Band gearbeitet. |
| `o` | Das vierstellige Großfeld wurde auf mindestens einem Band gearbeitet. |
| `xo` | Rufzeichen und Großfeld wurden bereits gearbeitet. |
`wkdany` ist eine bandunabhängige Übersicht. Das kleine `x` darf daher nicht mit dem großen `X` in einer Bandspalte verwechselt werden. Der globale Status wird für die Anzeige und den globalen **wkd**-Filter verwendet, nicht als Ersatz für bandbezogene Worked-Informationen.
### NOT-QRV-Markierungen
Teilt eine Station mit, dass sie auf einem bestimmten Band nicht QRV ist, kann dies im **Further Info**-Bereich der ausgewählten Station markiert werden:
1. Station in der Benutzerliste auswählen.
2. Im Bereich **Not QRV** das betreffende Band aktivieren.
3. **tag not qrv all** nur verwenden, wenn die Station auf keinem der unterstützten Bänder angefragt werden soll.
Angezeigt werden die einzelnen NOT-QRV-Schalter der Bänder, die für die eigene Station aktiviert sind. **tag not qrv all** setzt dagegen alle unterstützten Bänder, auch wenn einzelne davon momentan nicht in der Benutzeroberfläche eingeblendet sind. Die Markierung wird bandbezogen unter dem normalisierten Rufzeichen gespeichert und auf dessen aktive Chat-Varianten übertragen.
![Bandbezogene NOT-QRV-Markierungen im Further-Info-Bereich](not_qrv_controls.png)
NOT-QRV ist eine manuelle Korrektur und hat deshalb Vorrang vor automatisch erkannten QRGs und Bandangaben im Namensfeld. Das betreffende Band wird nicht mehr als `a` oder `B+` angeboten, vom **New bands**-Filter nicht als Gelegenheit gewertet und von den zugehörigen Bandfiltern ausgeblendet.
Im Klartext: Ein erkannter Hinweis bedeutet „wahrscheinlich auf diesem Band aktiv“. Ein manuelles NOT-QRV-Tag bedeutet „für unsere weitere Auswahl nicht auf diesem Band anfragen“. Diese Entscheidung soll nicht durch die nächste erkannte Zahl wieder aufgehoben werden.
### Speicherung und Lebensdauer
Worked-, NOT-QRV- und Großfeldinformationen werden in der internen SQLite-Datenbank gespeichert und beim nächsten Start wieder geladen. Die Einträge laufen nach drei Tagen automatisch ab. Ein Reset vor jedem Contest ist deshalb normalerweise nicht erforderlich.
Ein manueller Reset unter **Workedstn database** entfernt sämtliche Worked-Markierungen, NOT-QRV-Tags und gespeicherten Worked-Großfelder. Die bekannten Rufzeichenzeilen bleiben dabei in der Datenbank erhalten. Einzelheiten: [Worked Station Database Settings](de-Konfiguration#worked-station-database-settings-gearbeitete-stationen-datenbank).
Vor jedem Contest die Datenbank zurücksetzen: [Konfiguration Worked Station Database Settings](Konfiguration#worked-station-database-settings).
---
@@ -89,9 +235,19 @@ Stationen jenseits einer maximalen Entfernung ausblenden. Schaltfläche **„Sho
---
## Worked- und NOT-QRV-Filter
## Filter für Worked-Status, neue Bänder und neue Großfelder
Toggle-Buttons (einer pro Band) zum Ausblenden bereits gearbeiteter Stationen und/oder NOT-QRV-markierter Stationen. Der Filter wirkt **sofort** ohne manuelles Neu-Aktivieren (ab v1.22 live).
Die Filter oberhalb der Benutzerliste greifen auf dieselben Informationen zurück wie die Worked-Spalten:
- **wkd** blendet Rufzeichen aus, die auf mindestens einem Band gearbeitet wurden.
- Die einzelnen Band-Schaltflächen blenden Stationen aus, wenn das Rufzeichen auf diesem Band bereits gearbeitet oder für dieses Band manuell als NOT QRV markiert wurde.
- **New bands** zeigt nur Stationen, für die mindestens ein eigenes aktiviertes, noch nicht gearbeitetes Band bekannt ist. Berücksichtigt werden aktuelle QRG-Erkennungen und Bandangaben im Namensfeld; NOT-QRV hat Vorrang.
- **Only new grids** zeigt nur Stationen, deren vierstelliges Großfeld auf noch keinem Band gearbeitet wurde. Stationen ohne auswertbaren Locator erfüllen den Filter nicht.
- **Grid color** verändert die Liste nicht. Ist die Funktion aktiv, wird das QRA-Feld eines bereits gearbeiteten Großfelds dezent dunkler dargestellt. Neue Großfelder behalten die normale Tabellenfarbe.
Mehrere aktivierte Filter werden gemeinsam angewendet. Eine Station bleibt nur sichtbar, wenn sie alle gewählten Bedingungen erfüllt. Die Filter reagieren unmittelbar auf neue Logeinträge und geänderte NOT-QRV-Markierungen.
Bedienung und Aufbau der Filterleiste: [Benutzeroberfläche Filter](de-Benutzeroberflaeche#filter).
---
@@ -115,6 +271,22 @@ KST4Contest erkennt solche Nachrichten, die das eigene Rufzeichen enthalten, und
---
## Automatische Antworten auf Privatnachrichten (ab v1.25)
Nicht jede im ON4KST-Chat eingeloggte Station nimmt am gerade laufenden Contest teil. Trotzdem werden Sked-Anfragen während größerer Contests teilweise unkoordiniert und in großer Zahl an erreichbare Rufzeichen verteilt. Ohne automatische Antwort müssten diese Stationen immer wieder von Hand erklären, dass sie nicht mitfunken oder keine Skeds fahren.
KST4Contest kann darauf mit einem vorher festgelegten Text reagieren. Die eingehende Privatnachricht bleibt dabei sichtbar; sie wird weder blockiert noch verworfen. Davon getrennt lässt sich eine QRG-Antwort aktivieren, die auf typische Fragen wie `qrg?`, `freq?` oder `pse qrg` reagiert.
Bei zwei gleichzeitig geöffneten Chat-Kategorien bleibt der Zusammenhang erhalten: Die Antwort wird in der Kategorie der eingegangenen Nachricht gesendet. Eine QRG-Anfrage erhält außerdem nur die QRG dieser Kategorie und nicht eine Liste aller konfigurierten Frequenzen.
Automatische Antworten benötigen Grenzen. KST4Contest versieht sie daher mit `[KST4C Automsg]`, ignoriert entsprechend gekennzeichnete Nachrichten bei der allgemeinen und QRG-bezogenen Antwort und begrenzt weitere Antworten an dieselbe Station in derselben Kategorie auf eine Nachricht innerhalb von zwei Minuten. Der Schutz gilt gemeinsam für beide Antwortarten.
Im Klartext: Die Funktion verhindert keine Massenanfragen. Sie verhindert aber, dass der Empfänger jede davon einzeln mit derselben Absage beantworten muss. Sie soll keine Unterhaltung simulieren und erst recht keine endlose Diskussion mit einem zweiten automatischen Client beginnen.
Konfiguration, erkannte QRG-Anfragen und genaue Kategorienzuordnung: [Konfiguration Messagehandling Settings](de-Konfiguration#messagehandling-settings-ab-v125).
---
## Multi-Channel-Login (ab v1.26)
Gleichzeitiger Login in **zwei Chat-Kategorien** (z. B. 144 MHz und 432 MHz). Beide Chats werden parallel überwacht.
@@ -141,19 +313,86 @@ Für ausgewählte Stationen in der Benutzerliste gibt es direkte Buttons, um das
---
## Sked-Erinnerungen mit ALERT (ab v1.40)
## Skeds und Sked-Erinnerungen
Für jeden Chatmember kann ein Sked-Erinnerungsdienst mit automatischen Nachrichten aktiviert werden. Konfigurierbare Intervallmuster:
> Verfügbar ab v1.40; Band-, Rufzeichen- und Win-Test-Behandlung erweitert in Nightly / v1.42.
- **2+1 Minuten**: Nachrichten bei 2 min und 1 min vor dem Sked.
- **5+2+1 Minuten**: Nachrichten bei 5, 2 und 1 min vor dem Sked.
- **10+5+2+1 Minuten**: Nachrichten bei 10, 5, 2 und 1 min vor dem Sked.
Ein Sked ist mehr als eine Erinnerung an eine Uhrzeit. Er muss während des laufenden Contestbetriebs rechtzeitig sichtbar werden, die vereinbarte Station priorisieren und sofern gewünscht die Gegenstation noch einmal an den Termin erinnern.
Zusätzlich zu den Nachrichten an die Gegenstation gibt es eine **akustische und optische Benachrichtigung** für den eigenen Operator, sodass kein Sked vergessen wird.
KST4Contest behandelt deshalb drei voneinander unabhängige Aufgaben:
Aktivierung: FurtherInfo-Panel der entsprechenden Station.
1. Der Sked wird intern gespeichert und in die Prioritätsberechnung einbezogen.
2. Der Termin erscheint in der AP- und Sked-Timeline.
3. Optional werden vor dem Termin automatische Privatnachrichten gesendet.
Ist der Win-Test-Netzwerk-Listener aktiviert, versucht KST4Contest zusätzlich, den Sked an Win-Test zu übergeben. Ein Problem bei dieser Übergabe löscht oder verhindert den internen Sked nicht.
### Sked anlegen
Zuerst die gewünschte Station in der Benutzerliste auswählen. Die Bedienelemente befinden sich anschließend unten im Bereich **Further Info**.
| Bedienelement | Funktion |
|---|---|
| **Sked in** | Legt fest, in wie vielen Minuten der Sked stattfinden soll. Verfügbar sind 2 bis 15 sowie 20 Minuten. |
| **Band** | Wählt das Band des Skeds. Angeboten werden die unter **Station → my station uses …** aktivierten eigenen Bänder. |
| **Mode** | Legt den an Win-Test zu übertragenden Mode fest. Verfügbar sind `SSB` und `CW`. Die Auswahl hat keinen Einfluss auf den internen Sked oder die Reminder-PMs. |
| **Create sked** | Legt den internen Sked an und versucht bei aktiviertem Win-Test-Netzwerk-Listener zusätzlich die Übergabe an Win-Test. |
| **Remind-PM in** | Aktiviert die automatischen Privatnachrichten vor dem Termin. |
| **2+1**, **5+2+1**, **10+5+2+1** | Legt fest, wie viele Minuten vor dem Sked die Reminder-PMs gesendet werden. |
![Sked-Steuerung im Further-Info-Bereich](sked_controls.png)
KST4Contest versucht, ein sinnvolles Band vorzuwählen. Dafür werden nacheinander folgende Informationen verwendet:
1. eine höchstens 30 Minuten alte QRG der ausgewählten Station auf einem eigenen aktivierten Band,
2. eine eindeutige Bandangabe im Namensfeld der Station und
3. das erste aktivierte eigene Band.
Aktive Rufzeichenvarianten desselben Basisrufzeichens werden bei der Suche nach einer aktuellen Bandinformation gemeinsam betrachtet. Eine manuelle NOT-QRV-Markierung wird bei der automatischen Vorauswahl berücksichtigt. Das Band kann trotzdem ausdrücklich geändert werden, wenn der Operator bewusst eine andere Vereinbarung getroffen hat.
### Auswirkung auf den Priority Score
Ein eingetragener Sked erhöht den Score des normalisierten Basisrufzeichens:
| Zeitraum | Sked-Anteil am Score |
|---|---:|
| mehr als 15 Minuten vor dem Termin | `+40` |
| 15 bis 3 Minuten vor dem Termin | kontinuierlicher Anstieg von `+300` bis in Richtung `+1200` |
| weniger als 3 Minuten vor bis 1 Minute nach dem Termin | `+5000` |
| später als 1 Minute nach dem Termin | kein Sked-Boost mehr |
Die starke Gewichtung unmittelbar vor dem Termin ist beabsichtigt. Ein vereinbarter Sked soll dann nicht durch eine gerade sehr aktive, aber nicht fest eingeplante Station aus der Prioritätsliste verdrängt werden.
Der Score wird für das Basisrufzeichen berechnet. Ein Sked mit `DN9APW-2` beeinflusst daher auch den gemeinsamen Score weiterer aktiver Varianten von `DN9APW`. Das konkrete Nachrichtenziel bleibt trotzdem `DN9APW-2` in der beim Anlegen ausgewählten Chat-Kategorie.
Fünf Minuten nach dem Termin wird der Sked aus der internen Liste entfernt.
### Reminder-PMs
Reminder-PMs werden nur angelegt, wenn **Remind-PM in** aktiviert ist. Je nach ausgewähltem Muster sendet KST4Contest beispielsweise zwei und eine Minute vor dem Sked folgende Privatnachricht:
```text
[KST4C Autoreminder] sked in 2 min
```
Die Nachricht geht an das vollständige sichtbare KST-Rufzeichen und in die Chat-Kategorie, in der der Sked angelegt wurde. Ein Sked für `DN9APW-2` wird daher nicht versehentlich an `DN9APW`, `DN9APW-70` oder eine gleichnamige Station in einer anderen Kategorie gesendet.
Beim tatsächlichen Reminder zeigt KST4Contest zusätzlich den optischen **SKED**-Hinweis an. Ist die einfache Soundausgabe aktiviert, wird außerdem ein Hinweiston abgespielt. Das bloße Aktivieren des Reminders löst noch kein Blinken aus.
Wird für dasselbe vollständige Rufzeichen ein neuer Satz Reminder aktiviert, ersetzt dieser die zuvor geplanten Reminder dieses Rufzeichens.
### Speicherung und Grenzen
Skeds und Reminder-Zeitpläne werden nur im Arbeitsspeicher geführt. Nach einem Neustart von KST4Contest müssen noch benötigte Termine erneut angelegt werden.
Die automatische Bandvorauswahl ist eine Herleitung aus vorhandenen Chatinformationen. Sie beweist nicht, dass die Station noch auf der zuletzt genannten QRG arbeitet. Band, Uhrzeit und Mode sollten deshalb vor **Create sked** kontrolliert werden.
Bedienung: [Stationsinfo-Panel](de-Benutzeroberflaeche#stationsinfo-panel-further-info)
Darstellung: [AP- und Sked-Timeline](#ap-und-sked-timeline)
Win-Test-Übergabe: [Log-Synchronisation Win-Test](de-Log-Synchronisation#win-test)
---
## QSO-Monitoring (ab v1.31)
@@ -165,17 +404,23 @@ Konfiguration: [Konfiguration Sniffer-Einstellungen](de-Konfiguration#sniffe
---
## Win-Test-Integration (ab v1.31, vollständig ab v1.40)
## Win-Test-Integration
KST4Contest unterstützt [Win-Test](https://www.win-test.com/) vollständig als Logprogramm:
KST4Contest verwendet für Win-Test einen eigenen Listener für das native Win-Test-Netzwerkprotokoll. Darüber werden drei voneinander getrennte Funktionen bereitgestellt:
- **Log-Synchronisation**: Gearbeitete Stationen werden automatisch aus Win-Test übernommen und in der Benutzerliste markiert.
- **Frequenz-Auswertung**: Die aktuelle TRX-Frequenz wird aus Win-Test-UDP-Paketen ausgewertet und befüllt die `MYQRG`-Variable.
- **Sked-Übergabe (SKED Push via UDP)**: Vereinbarte Skeds aus KST4Contest können direkt an Win-Test übertragen werden, sodass das Rufzeichen der Gegenstation im Win-Test-Sked-Fenster erscheint.
- neue QSOs einschließlich Band- und gegebenenfalls Locatorinformation übernehmen,
- die aktuelle QRG aus Win-Test-STATUS-Paketen auswerten und
- intern angelegte Skeds als `ADDSKED` an das Win-Test-Netzwerk übergeben.
Bei der Sked-Übergabe wird die QRG nicht durch eine feste Standardfrequenz ersetzt. KST4Contest sendet nur dann einen Win-Test-Sked, wenn eine zum ausgewählten Band passende QRG ermittelt werden konnte. Der interne Sked, die Timeline und die Reminder-PMs funktionieren unabhängig davon weiter.
Ein sichtbarer KST-Suffix wie `-2`, `-70` oder `-144` bleibt innerhalb von KST4Contest erhalten, wird für das Win-Test-Logrufzeichen jedoch entfernt. Portable Bestandteile wie `/P`, `/M` oder ein Länderpräfix bleiben bestehen.
Einrichtung und genaue Datenbehandlung: [Log-Synchronisation Win-Test](de-Log-Synchronisation#win-test)
Einstellungen: [Win-Test-Netzwerk-Listener](de-Konfiguration#win-test-netzwerk-listener-ab-v131)
Details zur Konfiguration: [Konfiguration Win-Test-Netzwerk-Listener](de-Konfiguration#win-test-netzwerk-listener)
---
## PSTRotator-Interface (ab v1.31, vollständig ab v1.40)
@@ -185,50 +430,185 @@ Konfiguration: [Konfiguration PSTRotator-Einstellungen](de-Konfiguration#pst
---
## Band-Alert bei neuen QSOs (ab v1.40)
## Band-Upgrade-Hinweis nach einem Logeintrag
Wenn eine Station geloggt wird, prüft KST4Contest automatisch, ob diese Station im Chat weitere aktive Bänder angezeigt hat, auf denen man selbst ebenfalls QRV ist. Falls ja, erscheint ein **Hinweis-Alert**, damit keine Multi-Band-Möglichkeit übersehen wird.
Meldet UCXLog oder Win-Test einen neuen Logeintrag mit Bandinformation, prüft KST4Contest, ob die gearbeitete Station noch ein weiteres gemeinsames Band anbietet.
Die Herleitung verwendet dieselben Regeln wie `a`, `B+` und der Filter **New bands**: aktivierte eigene Bänder, aktuelle QRG-Erkennungen, Bandangaben im Namensfeld, bandbezogene Worked-Markierungen und NOT-QRV-Tags. Ausgewertet werden die aktiven Chat-Varianten desselben normalisierten Rufzeichens.
Bleibt mindestens ein gemeinsames, noch nicht gearbeitetes Band übrig, erscheint für ungefähr zwölf Sekunden ein blinkender Hinweis mit Rufzeichen und den betreffenden Bändern, beispielsweise `BAND+ DL0ABC 432, 1296`. Der Tooltip zeigt zusätzlich die bei der Entscheidung berücksichtigten aktivierten, gearbeiteten und als NOT QRV markierten Bänder. Ist die allgemeine Soundausgabe eingeschaltet, wird außerdem ein kurzer Hinweiston abgespielt.
Der einfache Simplelogfile-Interpreter kann diesen Hinweis nicht zuverlässig auslösen, weil er keine Bandinformation für das gerade geloggte QSO liefert.
Konfiguration: [Band-Upgrade-Hinweis nach einem Logeintrag](de-Konfiguration#band-upgrade-hinweis-nach-einem-logeintrag).
Worked-, NOT-QRV- und Großfelddaten laufen nach drei Tagen automatisch ab. Einzelheiten und manueller Reset: [Worked Station Database Settings](de-Konfiguration#worked-station-database-settings-gearbeitete-stationen-datenbank).
---
## Prioritätsscore und Prioritätsliste (ab v1.40)
### Warum wird überhaupt ein Score benötigt?
Eine klassische Chat-Benutzerliste zeigt zunächst nur, welche Stationen gerade eingeloggt sind. Im Contestbetrieb reicht diese Information nicht aus. Der Operator muss zusätzlich abschätzen, welche Station noch nicht gearbeitet wurde, auf welchem Band ein QSO möglich sein könnte, wohin die Antenne zeigt, ob ein passendes Flugzeug verfügbar ist und ob ein vereinbarter Sked unmittelbar bevorsteht.
Bei einer kurzen Liste lässt sich das noch im Kopf erledigen. Mit zunehmender Contestdauer, mehreren Bändern und zwei gleichzeitig verwendeten Chat-Kategorien wird daraus jedoch eine ständig wiederholte Entscheidung.
KST4Contest führt die bereits vorhandenen Informationen deshalb in einem Prioritätsscore zusammen. Der Score beantwortet nicht die Frage, ob ein QSO sicher möglich ist. Er hilft bei der praktisch wichtigeren Frage:
> Welche der aktuell sichtbaren Stationen sollte ich mir als Nächstes ansehen?
### Wann wird eine Station ausgeschlossen?
Vor der eigentlichen Gewichtung prüft KST4Contest, ob überhaupt eine bekannte Bandmöglichkeit besteht. Dafür werden alle aktiven Chat-Einträge desselben normalisierten Basisrufzeichens gemeinsam ausgewertet.
Berücksichtigt werden:
1. die in den Stationseinstellungen aktivierten eigenen Bänder,
2. höchstens 30 Minuten alte QRG-Erkennungen der Gegenstation,
3. eindeutige Bandangaben im Namensfeld ihrer aktiven Chat-Einträge,
4. die pro Band gespeicherten Worked-Markierungen und
5. manuell gesetzte NOT-QRV-Tags.
NOT QRV hat dabei Vorrang vor automatisch erkannten Frequenzen oder Bandangaben.
Sind Bänder der Gegenstation bekannt, aber keines davon ist lokal aktiviert und noch verfügbar, erhält die Station einen Score von `0`. Dasselbe gilt, wenn alle gemeinsam möglichen Bänder bereits gearbeitet wurden.
Fehlen dagegen sämtliche Bandinformationen, wird die Station nicht allein deshalb ausgeschlossen. Eine unbekannte Bandmöglichkeit ist nicht dasselbe wie eine nachweislich unmögliche Bandmöglichkeit. Erst wenn alle eigenen aktivierten Bänder für die Station manuell als NOT QRV markiert wurden, ist auch in diesem Fall keine aktuelle Contestmöglichkeit mehr vorhanden.
Stationen mit einem Score von `0` bleiben in der Benutzerliste sichtbar, erscheinen aber nicht in der Prioritätsliste.
### Welche Informationen erhöhen oder verringern den Score?
Der Score entsteht aus mehreren voneinander unabhängigen Hinweisen. Ein einzelnes Kriterium entscheidet daher normalerweise nicht über den endgültigen Listenplatz.
| Faktor | Wirkung auf die Priorisierung |
|---|---|
| Worked-Status | Ein noch auf keinem unterstützten Band gearbeitetes Rufzeichen erhält eine höhere Ausgangspriorität. Bereits gearbeitete Stationen werden niedriger bewertet, bleiben bei offenen Bandmöglichkeiten aber Kandidaten. |
| Verfügbare Bänder | Mehrere gemeinsam nutzbare und noch nicht gearbeitete Bänder erhöhen die Priorität. Optional kann für Band-Upgrades ein zusätzlicher Boost aktiviert werden. |
| Entfernung | Entfernungen unter 200 km werden niedriger gewichtet. Der Bereich zwischen 200 km und dem konfigurierten maximalen QRB wird bevorzugt. Stationen jenseits des maximalen QRB werden deutlich herabgestuft. Fehlt der QRB, entfällt dieser Faktor. |
| Antennenrichtung | Liegt der QTF zur Gegenstation innerhalb der Hälfte des konfigurierten Antennen-Öffnungswinkels um den aktuellen eigenen QTF, steigt der Score. Je näher die Richtungen zusammenliegen, desto stärker wirkt der Hinweis. |
| AirScout | Mindestens ein aktuell erreichbares Flugzeug erhöht den Score. Eine erwartete AP-Gelegenheit in null, einer oder zwei Minuten wird zusätzlich zeitlich gewichtet. |
| Aktuelle Chat-Aktivität | Eine Nachricht innerhalb der letzten Minute wirkt stärker als eine Nachricht innerhalb der letzten drei Minuten. Mehrere eingehende Zeilen innerhalb des Aktivitätsfensters erhöhen den Score zusätzlich. |
| Positive Signale | Erkannte Angaben wie `QRV`, `READY`, `RGR`, `OK`, `TNX` oder vergleichbare konfigurierte Textmuster werden für einige Minuten als positiver Hinweis berücksichtigt. |
| Antwortverhalten | Reagiert eine Station nach einer eigenen `/cq`-Nachricht schnell mit einer weiteren sichtbaren Chat-Zeile, wirkt sich die gemittelte Reaktionszeit positiv aus. Bleibt eine solche Zeile aus, entsteht nach dem konfigurierten Timeout eine negative Bewertung. |
| Skeds | Ein eingetragener Sked erhöht die Priorität zunächst leicht. Innerhalb der letzten 15 Minuten vor dem Termin steigt der Einfluss kontinuierlich an. Zwischen drei Minuten vor und einer Minute nach dem Termin erhält der Sked eine sehr hohe Priorität. |
| Fehlgeschlagener Versuch | **Sked fail** reduziert den Score der Station stark, bis die Markierung mit **Reset fail** zurückgesetzt oder KST4Contest neu gestartet wird. |
Das standardmäßige Aktivitätsfenster für die Anzahl eingehender Nachrichten beträgt 180 Sekunden. Eine aktuelle Nachricht innerhalb der letzten 60 Sekunden wird noch einmal gesondert bewertet. Der standardmäßige No-Reply-Timeout beträgt 13 Minuten.
Beim Antwortverhalten kann KST4Contest nicht sicher feststellen, ob eine nachfolgende öffentliche oder private Nachricht tatsächlich die Antwort auf die eigene Anfrage war. Jede anschließend empfangene Zeile derselben Station beendet deshalb den laufenden Antwortzeitversuch. Der Wert ist eine praktische Näherung und keine statistisch belastbare Antwortquote.
### Was bedeutet ein eingetragener Sked?
Ein Sked ist eine zeitlich vereinbarte Arbeitsaufgabe. Deshalb übersteuert ein unmittelbar bevorstehender Sked die meisten normalen Aktivitäts- und Entfernungshinweise. Ohne diese Gewichtung könnte eine gerade sehr aktive Station einen vereinbarten Termin aus der Prioritätsliste verdrängen.
Der starke Sked-Boost ist absichtlich auf den Zeitraum von drei Minuten vor bis eine Minute nach dem eingetragenen Termin begrenzt. Ein weiter in der Zukunft liegender Sked bleibt sichtbar, soll den laufenden Betrieb aber noch nicht dominieren.
Die Bewertung wird für das normalisierte Basisrufzeichen vorgenommen. Ein Sked für eine aktive Variante wie `9A0BB-23` beeinflusst daher den gemeinsamen Score der zu `9A0BB` gehörenden Chat-Einträge.
### Wie werden mehrere SSIDs und Chat-Kategorien behandelt?
Aktive Rufzeichen wie `9A0BB-2`, `9A0BB-70`, `9A0BB-23` und `9A0BB-13` bleiben getrennte Chatmember. Dadurch können Nachrichten weiterhin an das vollständige Rufzeichen und die richtige Chat-Kategorie adressiert werden.
Worked-, Band-, NOT-QRV- und Score-Informationen beziehen sich dagegen auf das gemeinsame Basisrufzeichen `9A0BB`. Der Score wird deshalb einmal berechnet und auf alle aktiven Varianten übertragen. Die Benutzerliste kann mehrere getrennte Zeilen mit demselben Score enthalten; in der Prioritätsliste erscheint das Basisrufzeichen nur einmal.
Als konkretes Nachrichtenziel verwendet KST4Contest den zuletzt passenden aktiven Login in der zuletzt verwendeten Chat-Kategorie. Beim Anklicken eines Kandidaten wird anschließend das vollständige Rufzeichen einschließlich Suffix und Kategorie ausgewählt.
### Aktualisierung und Anzeige
Änderungen durch neue Nachrichten, AirScout-Daten, Skeds, Worked-Informationen oder manuelle NOT-QRV- und Sked-fail-Markierungen fordern unmittelbar eine Neuberechnung an. Zusätzlich wird der Score regelmäßig im Hintergrund aktualisiert, weil Aktivitäts-, AP- und Sked-Informationen auch ohne neues Ereignis altern.
Eine kurze Verzögerung von einigen Sekunden zwischen einem Ereignis und der sichtbaren neuen Reihenfolge ist daher normal.
Die Benutzeroberfläche zeigt den Score an drei Stellen:
- als numerisch sortierbare Spalte **Score** in der Benutzerliste,
- für die ausgewählte Station im Bereich **Further Info** und
- als kompakte Liste der beiden derzeit höchstbewerteten Kandidaten mit einem zusätzlichen Fenster für bis zu 15 Kandidaten.
Bedienung: [Prioritätsliste in der Benutzeroberfläche](de-Benutzeroberflaeche#prioritätsliste).
### Was sagt der Score nicht aus?
Der Zahlenwert ist weder eine Erfolgswahrscheinlichkeit noch eine Signalprognose. Ein doppelt so hoher Score bedeutet nicht, dass ein QSO doppelt so wahrscheinlich ist.
Die Berechnung kennt unter anderem nicht:
- die tatsächliche Antennenrichtung der Gegenstation,
- deren momentane Betriebssituation,
- lokale Störungen,
- kurzfristige Ausbreitungsänderungen,
- Geländeabschattungen außerhalb der jeweils angebundenen Funktionen oder
- die Frage, ob eine im Chat aktive Station tatsächlich gerade am Funkgerät sitzt.
Auch bekannte Eingabedaten können veraltet oder missverständlich sein. Eine erkannte Frequenz belegt beispielsweise nur, dass diese QRG kürzlich im Zusammenhang mit der Station aufgetreten ist.
Im Klartext: Der Score ersetzt nicht die Entscheidung des Operators. Er sorgt dafür, dass die dafür bereits vorhandenen Informationen nicht bei jedem Kandidaten erneut im Kopf zusammengesucht werden müssen.
Zugehörige Einstellungen:
- [Aktivierte Bänder](de-Konfiguration#aktivierte-bänder)
- [Antennen-Öffnungswinkel](de-Konfiguration#antennen-öffnungswinkel-antenna-beamwidth)
- [Standard-Maximum-QRB](de-Konfiguration#standard-maximum-qrb)
- [AirScout-Einstellungen](de-Konfiguration#airscout-einstellungen)
- [Band-Upgrade-Hinweis und Priority Boost](de-Konfiguration#band-upgrade-hinweis-nach-einem-logeintrag)
---
## Worked-Tag-Lebensdauer (ab v1.40)
## AP- und Sked-Timeline
Gearbeitete Stationen werden nach **3 Tagen** automatisch aus der Datenbank entfernt. Ein manuelles Zurücksetzen der Worked-Datenbank vor jedem Contest ist damit nicht mehr zwingend notwendig die Datenbank hält sich selbst aktuell.
Die Timeline stellt bevorstehende Aircraft-Scatter-Gelegenheiten und eingetragene Skeds für die nächsten 30 Minuten gemeinsam dar. Sie beantwortet damit zwei Fragen auf einen Blick:
---
- Wann entsteht voraussichtlich eine interessante AP-Gelegenheit?
- Welcher bereits vereinbarte Sked nähert sich unabhängig davon?
## Chatmember Score-System / Prioritätsliste (ab v1.40)
Weiter in der Zukunft liegende Ereignisse erscheinen rechts. Mit ablaufender Zeit wandern sie nach links in Richtung des aktuellen Zeitpunkts.
KST4Contest berechnet automatisch eine **Prioritätsbewertung** für jeden aktiven Chatmember. Der Score setzt sich zusammen aus:
![AP-Kandidaten und Skeds in der Timeline](sked_timeline.png)
- Antennenrichtung der Gegenstation (zeigt sie auf mich?)
- QRB (Entfernung)
- Aktivitätszeit und Nachrichtenanzahl
- Aktive Bänder und Frequenzen
- AP-Verfügbarkeit (AirScout)
- Sked-Richtung
- Sked-Erfolgsrate und Skedfail-Markierungen
### AP-Kandidaten
Die Top-Kandidaten werden in einer eigenen Prioritätsliste hervorgehoben und helfen, im Contest-Stress die wichtigsten Stationen nicht zu übersehen.
AP-Kandidaten erscheinen in den oberen Spuren. Pro Ankunftsminute können bis zu vier ausgewählte Kandidaten dargestellt werden. Die Auswahl berücksichtigt den Priority Score und das von AirScout gemeldete Reflexionspotenzial.
Stationen, bei denen ein Sked gescheitert ist, können über den **Skedfail-Button** im FurtherInfo-Panel markiert werden das senkt ihren Score vorübergehend.
Die Farbe des AP-Symbols kennzeichnet das Reflexionspotenzial:
---
| Farbe | Reflexionspotenzial |
|---|---:|
| Magenta | mindestens 95 % |
| Rot | mindestens 75 % |
| Gelb | mindestens 50 % |
| Blau | unter 50 % |
## AP-Timeline (ab v1.40)
Die Farbe ist keine QSO-Wahrscheinlichkeit. Sie gibt den von AirScout übernommenen Wert für die berechnete Reflexionsgeometrie wieder.
Eine visuelle Zeitleiste zeigt für jeden möglichen AP-Ankunftsminuten-Slot bis zu 4 hochbewertete Stationen, die per Aircraft Scatter erreichbar wären. Priorisierungskriterien:
Ein Klick auf einen AP-Kandidaten wählt den dazugehörigen aktiven Chatmember einschließlich Rufzeichensuffix und Chat-Kategorie aus. Dadurch kann unmittelbar eine passende Nachricht vorbereitet werden.
- Bevorzugt werden APs mit dem **höchsten Reflexionspotenzial** (nicht unbedingt die schnellste Ankunft).
- Stationen, auf die die eigene Antenne nicht zeigt, werden **transparent** dargestellt.
### Skeds
So kann der Contest-Operator auf einem Blick sehen, welche Stationen wann und über welche Flugzeuge erreichbar sein werden.
Skeds erscheinen als Rauten in der unteren Spur. Die Beschriftung verwendet das vollständige KST-Rufzeichen, beispielsweise `SKED: DN9APW-2`. Dadurch bleibt erkennbar, welcher konkrete Login für den Termin ausgewählt wurde.
---
Der Tooltip eines Skeds zeigt mindestens:
- das vollständige KST-Rufzeichen,
- das vereinbarte Band und
- den QTF zur Gegenstation.
Sind passende AirScout-Daten vorhanden, werden zusätzlich die aktuelle AP-Erreichbarkeit und die nächste berechnete AP-Gelegenheit angezeigt.
### Berücksichtigung der Antennenrichtung
Liegt der QTF eines Ereignisses deutlich außerhalb der aktuellen Antennenrichtung, wird dessen Symbol transparenter dargestellt. Die Beschriftung bleibt lesbar. Liegt das Ziel nahe der Mitte des konfigurierten Antennenbereichs, wird das Symbol zusätzlich hervorgehoben.
Diese Darstellung verändert weder den Sked noch den Priority Score. Sie ist eine optische Hilfe, um Kandidaten in der aktuellen Antennenrichtung schneller zu erkennen.
Die Timeline ist eine Vorschau. AirScout-Daten können sich ändern, und ein eingetragener Sked garantiert weder eine freie Frequenz noch eine tatsächlich vorhandene Ausbreitungsverbindung.
## Intervall-Beacon
Automatische CQ-Meldungen im öffentlichen Kanal in konfigurierbarem Intervall. Empfohlene Verwendung mit der Variable `MYQRG` für aktuelle Frequenzangabe. Details: [Konfiguration Beacon Settings](Konfiguration#beacon-settings-automatischer-beacon).
KST4Contest kann wiederkehrende CQ-Nachrichten in den öffentlichen Chat senden. Beide Chat-Kategorien verwenden ein gemeinsames Intervall, besitzen aber jeweils einen eigenen Aktivierungsschalter und Nachrichtentext. Globale Variablen wie `MYQRG`, `SECONDQRG` oder `MYLOCATOR` werden unmittelbar vor jeder Aussendung aktualisiert.
Der Beacon ist für längeres CQ-Rufen auf einer festen Frequenz gedacht. Beim Absuchen oder häufigen Wechseln der QRG sollte er ausgeschaltet werden, damit keine inzwischen falsche Frequenz verbreitet wird. Details: [Konfiguration Beacon Settings](de-Konfiguration#beacon-settings-automatischer-beacon).
---
@@ -242,7 +622,7 @@ Dateibasierte Log-Auswertung per Regex. Details: [Log-Synchronisation](Log-Synch
Ein separates Fenster zeigt den QSO-Fluss zwischen anderen Stationen. Besonders interessant in ruhigeren Nacht-Stunden während des Contests, wenn weniger Verkehr herrscht.
Dieses Fenster kann miniaturisiert werden, wenn es nicht benötigt wird. Zukünftig geplant: Filterung auf Stationen im ausgewählten QTF.
Dieses Fenster kann minimiert werden, wenn es nicht benötigt wird. Zukünftig geplant: Filterung auf Stationen im ausgewählten QTF.
---
+238 -37
View File
@@ -25,17 +25,40 @@ Eigenes Rufzeichen und Maidenhead-Locator (6-stellig, z. B. `JN49IJ`) eintragen.
### Aktivierte Bänder
Über die **„my station uses band"**-Checkboxen werden die aktiven Bänder ausgewählt. Nur für ausgewählte Bänder erscheinen Schaltflächen und Tabellenzeilen in der Benutzeroberfläche. Nach Änderungen muss die Software neu gestartet werden.
Über die Checkboxen **My station uses …** wird festgelegt, auf welchen Bändern die eigene Station im aktuellen Setup arbeiten kann. Unterstützt werden 50 MHz, 70 MHz, 144 MHz, 432 MHz, 1296 MHz, 2320 MHz, 3400 MHz, 5760 MHz und 10 GHz.
Die Auswahl steuert nicht nur die sichtbaren Bandspalten. Sie wird außerdem verwendet für:
- die bandbezogenen Worked- und NOT-QRV-Filter,
- die im **Further Info**-Bereich sichtbaren NOT-QRV-Schalter,
- die Herleitung von `a`- und `B+`-Bandmöglichkeiten,
- den Filter **New bands**,
- den Band-Upgrade-Hinweis nach einem Logeintrag und
- bandbezogene Prioritäts- und Reachability-Funktionen.
Nach einer Änderung **Save Settings** verwenden und KST4Contest neu starten. Die Bandspalten und mehrere zugehörige Bedienelemente werden beim Aufbau der Benutzeroberfläche erzeugt und deshalb nicht vollständig in der laufenden Sitzung ergänzt oder entfernt.
### Antennen-Öffnungswinkel (Antenna Beamwidth)
Einen realistischen Wert für den Öffnungswinkel der eigenen Antenne eintragen (in Grad). Dieser Wert wird für die [Sked-Richtungs-Hervorhebung](Funktionen#sked-richtungs-hervorhebung) verwendet. Ein Testwert von 50° hat sich bewährt; DM5M nutzt Quads mit 69°.
Trage den vollständigen horizontalen Öffnungswinkel der eigenen Antenne in Grad ein. KST4Contest verwendet jeweils die Hälfte dieses Werts links und rechts der gewählten beziehungsweise hergeleiteten Antennenrichtung. Ein eingetragener Wert von `70°` entspricht daher einem Korridor von `±35°`.
> **Keinesfalls** Fantasy-Werte eintragen die Richtungsberechnungen werden sonst unbrauchbar.
Der Wert wird an mehreren Stellen verwendet:
- für den QTF-Filter der Benutzerliste,
- für die Darstellung des eigenen Antennenkorridors,
- als angenommener Öffnungswinkel einer fremden Station bei der [Herleitung von Richtungsgelegenheiten](de-Funktionen#richtungsgelegenheiten-aus-gerichteten-nachrichten).
Der letzte Punkt ist bewusst eine Näherung. ON4KST überträgt weder die verwendete Antenne noch deren Öffnungswinkel. KST4Contest verwendet deshalb den eigenen Wert als praktikable Annahme für die Gegenstation.
Wähle einen realistischen Wert. Ein zu großer Öffnungswinkel erzeugt viele geometrische Treffer, die praktisch kaum noch eine Aussage haben. Ein zu kleiner Wert kann dagegen brauchbare Richtungsgelegenheiten ausblenden.
### Standard-Maximum-QRB
Maximale Entfernung (in km), für die Richtungs-Warnungen ausgelöst werden sollen. Realistischer Wert für DM5M: 900 km. Stationen, die weiter entfernt sind, werden für Highlighting-Zwecke ignoriert.
Trage die maximale Entfernung in Kilometern ein, innerhalb der KST4Contest Richtungsgelegenheiten berücksichtigen soll. Maßgeblich ist die Entfernung zwischen der eigenen Station und dem Absender der gerichteten Nachricht nicht die Entfernung zwischen Absender und Empfänger.
Liegt der Absender weiter entfernt, wird die Situation auch dann nicht hervorgehoben und nicht als Richtungsgelegenheit an den lokalen DX-Cluster-Server weitergegeben, wenn der berechnete Winkel passen würde.
Der Wert sollte zum eigenen Stationsaufbau und zum vorgesehenen Contestbetrieb passen. Ein unnötig großer Bereich erzeugt Hinweise für Stationen, die praktisch nicht mehr zum Arbeitsbereich gehören; ein zu kleiner Bereich blendet mögliche Kandidaten bereits vor der Richtungsbewertung aus.
---
@@ -101,41 +124,79 @@ Die drei Audiofunktionen arbeiten unabhängig voneinander:
CW- und Sprachausgabe können gleichzeitig aktiviert werden. Das ist technisch möglich, im Contest aber nicht zwingend hilfreich. In der Praxis sollte nur die Ausgabe eingeschaltet werden, die im eigenen Stationsbetrieb tatsächlich wahrgenommen werden kann, ohne den Operator dauerhaft zu beschäftigen.
### Fallback-Band für relative QRG-Erkennung
Das Dropdown **Fallback band for relative QRG detection** legt fest, welches Band KST4Contest verwendet, wenn eine relative QRG keinem aktuellen Stationskontext zugeordnet werden kann.
Zur Auswahl stehen ausschließlich die vom Frequenzparser unterstützten Bandpräfixe:
```text
50 MHz
70 MHz
144 MHz
432 MHz
1296 MHz
2320 MHz
3400 MHz
5760 MHz
10368 MHz (10G)
24048 MHz (24G)
```
Das Dropdown ist kein Filter und keine Vorgabe für vollständig angegebene Frequenzen. `432.088` wird unabhängig von der Auswahl als Frequenz im 432-MHz-Band erkannt. Benötigt wird das Fallback bei relativen Angaben wie `.205`, `,205` oder `qrg 205`.
Bevor KST4Contest auf das Fallback zurückgreift, prüft es den Bandkontext des Absenders. Wurde für dieselbe Station innerhalb der letzten 30 Minuten bereits eine passende vollständige Frequenz erkannt, hat dieses Band Vorrang. Ein Fallback von `144 MHz` macht aus `.100` daher `432.100 MHz`, wenn die Station kurz zuvor beispielsweise `432.088` genannt hat.
Die Einstellung befindet sich im Notification-Bereich, wirkt aber auf die gesamte QRG-Erkennung. Damit beeinflusst sie nicht nur mögliche DX-Cluster-Spots, sondern auch die QRG-Spalte, erkannte aktive Bänder, Priorisierung, Band-Upgrade-Hinweise und Funktionen, die eine bekannte Stationsfrequenz verwenden.
Mehr zur Erkennungslogik und zu absichtlich ignorierten Zahlen: [QRG-Erkennung](de-Funktionen#qrg-erkennung).
### Local DX Cluster output
KST4Contest kann erkannte Richtungsgelegenheiten als DX-Cluster-Spots an ein Logprogramm weitergeben. Der praktische Nutzen liegt auf der Hand: Eine im Chat erkannte Frequenz erscheint direkt in der Bandmap des Logprogramms und muss nicht erst von Hand übertragen werden.
KST4Contest kann erkannte Richtungsgelegenheiten als DX-Cluster-Spots an ein Logprogramm weitergeben. Eine im Chat erkannte Frequenz erscheint dadurch direkt in der Bandmap des Logprogramms und muss nicht erst von Hand übertragen werden.
Die Checkbox **Enable the local DX Cluster server …** startet beziehungsweise beendet den lokalen TCP-Server. Bei einer laufenden Chat-Verbindung wird die Änderung sofort wirksam.
Folgende Einstellungen sind erforderlich:
Folgende Einstellungen und Schaltflächen gehören zur lokalen DX-Cluster-Ausgabe:
- **TCP port**: Port, auf dem KST4Contest Verbindungen von DX-Cluster-Clients annimmt. Der Standardwert ist `8000`. Wird der Port während einer laufenden Verbindung geändert, startet KST4Contest den Server auf dem neuen Port neu. Der Logger muss sich anschließend ebenfalls mit dem neuen Port verbinden.
- **Fallback band in MHz**: Bandpräfix für relative Frequenzangaben. Aus `205` oder `.205` wird bei einem Fallback-Band von `144` die Frequenz `144.205 MHz`. Vollständige Angaben wie `432.205` oder `1296.338` benötigen diesen Fallback nicht.
- **Fallback band for relative QRG detection**: Das oben beschriebene globale Fallback-Band. Der Testspot verwendet `.300` dieses Bandes. Reale Spots verwenden dagegen die für den jeweiligen Absender erkannte QRG.
- **Spotter callsign**: Rufzeichen, das im erzeugten DX-Cluster-Spot als Spotter erscheint. Hier sollte ein anderes Rufzeichen als das im Contest verwendete Stationsrufzeichen eingetragen werden. Einige Logprogramme filtern Spots des eigenen Rufzeichens oder behandeln sie anders als fremde Spots.
- **Send test spot**: Sendet einen Testspot für `DL0TEST` auf `.300` des eingestellten Fallback-Bandes. Der Test funktioniert nur, wenn KST4Contest mit dem Chat verbunden, der lokale DX-Cluster-Server aktiviert und mindestens ein DX-Cluster-Client verbunden ist.
- **Send test spot**: Sendet einen Testspot für `DL0TEST` auf `.300` des ausgewählten Fallback-Bandes. Der Test funktioniert nur, wenn KST4Contest mit dem Chat verbunden, der lokale DX-Cluster-Server aktiviert und mindestens ein DX-Cluster-Client verbunden ist.
KST4Contest erzeugt nicht bei jeder im Chat gefundenen Frequenz automatisch einen Spot. Ein Spot entsteht nur dann, wenn eine gerichtete Nachricht zwischen zwei Stationen auf eine für die eigene Station interessante Antennenrichtung schließen lässt und für den Absender eine nutzbare Frequenz bekannt ist.
Die vollständige Herleitung und die Einrichtung des Logprogramms sind im Kapitel [Integrierter DX-Cluster-Server](de-DX-Cluster-Server) beschrieben.
### Band-Upgrade-Hinweis nach einem Logeintrag
Nach einem über UCXLog oder Win-Test empfangenen Logeintrag kann KST4Contest prüfen, ob die gerade gearbeitete Station auf einem weiteren gemeinsamen, aber noch nicht gearbeiteten Band aktiv ist.
Nach einem über UCXLog oder Win-Test empfangenen Logeintrag kann KST4Contest prüfen, ob die gerade gearbeitete Station noch ein weiteres gemeinsames, aber bisher nicht gearbeitetes Band anbietet.
Dafür werden drei Informationen miteinander verglichen:
Die Prüfung verwendet dieselbe Bandherleitung wie die `a`- und `B+`-Anzeige:
1. die in den Stationseinstellungen aktivierten eigenen Bänder,
2. die innerhalb der letzten 30 Minuten erkannten Bänder der Gegenstation,
3. die bereits pro Band gespeicherten Worked-Markierungen.
2. höchstens 30 Minuten alte QRG-Erkennungen der Gegenstation,
3. eindeutige Bandangaben im Namensfeld ihrer aktiven Chat-Einträge,
4. die pro Band gespeicherten Worked-Markierungen und
5. manuell gesetzte NOT-QRV-Tags.
Bleibt danach mindestens ein gemeinsames, noch nicht gearbeitetes Band übrig, erscheint im Hauptfenster ein blinkender **BAND+**-Hinweis. Ist die allgemeine Soundausgabe aktiviert, wird zusätzlich ein Hinweiston abgespielt.
Aktive Chat-Varianten desselben normalisierten Rufzeichens werden gemeinsam ausgewertet. NOT-QRV hat Vorrang vor einer automatisch erkannten QRG oder Bandangabe.
Bleibt mindestens ein gemeinsames, noch nicht gearbeitetes Band übrig, erscheint im Hauptfenster für ungefähr zwölf Sekunden ein blinkender **BAND+**-Hinweis mit Rufzeichen und den noch offenen Bändern. Der Tooltip zeigt die vollständige Herleitung. Ist die allgemeine Soundausgabe aktiviert, wird zusätzlich ein kurzer Hinweiston abgespielt.
Die beiden Optionen haben unterschiedliche Aufgaben:
- **Blink + sound …** aktiviert den eigentlichen Band-Upgrade-Hinweis.
- **Priority boost …** erhöht zusätzlich die Priorität entsprechender Stationen, damit sie in den Kandidatenlisten besser sichtbar bleiben. Der Boost garantiert keinen bestimmten Listenplatz; er ist nur ein zusätzlicher Faktor innerhalb der gesamten Prioritätsberechnung.
- **Blink + sound …** aktiviert den Hinweis nach einem passenden Logeintrag.
- **Priority boost …** erhöht zusätzlich den Score von Stationen, die bereits auf mindestens einem Band gearbeitet wurden, aber noch ein weiteres gemeinsames und nicht gearbeitetes Band anbieten.
Der Hinweis setzt eine Log-Synchronisation mit Bandinformation voraus. Der einfache dateibasierte Callsign-Interpreter kann nur Rufzeichen erkennen und liefert deshalb keine ausreichende Grundlage für diese Prüfung.
Der Priority Boost ist nur ein Faktor innerhalb der gesamten Berechnung. Entfernung, Antennenrichtung, aktuelle Aktivität, AirScout-Daten, Skeds und negative Hinweise können den endgültigen Listenplatz weiterhin verändern. Die aktivierte Option garantiert deshalb weder einen bestimmten Score noch einen bestimmten Platz in der Prioritätsliste.
Die übrigen Score-Gewichte besitzen derzeit keine eigenen Bedienelemente. Mehrere vorhandene Einstellungen liefern jedoch Eingangsdaten für die Berechnung, insbesondere die [aktivierten Bänder](#aktivierte-bänder), der [Antennen-Öffnungswinkel](#antennen-öffnungswinkel-antenna-beamwidth), der [Standard-Maximum-QRB](#standard-maximum-qrb) und die [AirScout-Einstellungen](#airscout-einstellungen).
Die vollständige Herleitung ist unter [Prioritätsscore und Prioritätsliste](de-Funktionen#prioritätsscore-und-prioritätsliste-ab-v140) beschrieben.
Der Hinweis setzt eine Log-Synchronisation mit Bandinformation voraus. Der einfache dateibasierte Callsign-Interpreter erkennt lediglich Rufzeichen und liefert deshalb keine sichere Information über das Band des gerade geloggten QSOs.
Weitere Hintergründe: [Band-Upgrade-Hinweis nach einem Logeintrag](de-Funktionen#band-upgrade-hinweis-nach-einem-logeintrag).
### Sniffer-Einstellungen (ab v1.31)
@@ -183,38 +244,155 @@ Wenn in der Benutzerliste ein Rufzeichen ausgewählt ist, wird der Snippet als D
## Beacon Settings (Automatischer Beacon)
Konfiguration eines automatischen Intervall-Beacons im öffentlichen Chat-Kanal. Empfohlen: Variable `MYQRG` im Text verwenden, damit die aktuelle Frequenz immer aktuell ist. Intervall und Text sind frei konfigurierbar.
![Beacon-Einstellungen](client_settings_window_beacon.png)
> **Tipp**: Beacon beim CQ-Rufen aktivieren und im Einstellungsfenster schnell deaktivieren, wenn kein CQ gerufen wird.
Ein Beacon sendet in regelmäßigen Abständen eine öffentliche CQ-Nachricht. Er ist für Betriebssituationen gedacht, in denen die eigene Station über längere Zeit auf einer festen Frequenz ruft. Andere Stationen erhalten dadurch eine aktuelle QRG-Information, ohne dass der Operator denselben Text wiederholt von Hand in den Chat schreiben muss.
KST4Contest verwendet einen gemeinsamen Timer für beide Chat-Kategorien. Aktivierung und Nachrichtentext werden trotzdem getrennt konfiguriert:
- **Enable CQ beacon** aktiviert den Beacon der betreffenden Kategorie.
- **Beacon message** enthält den öffentlichen Nachrichtentext dieser Kategorie.
- **Shared beacon interval** legt das gemeinsame Intervall für beide Kategorien fest.
Sind beide Beacons aktiviert, werden sie beim selben Timer-Lauf nacheinander in ihren jeweiligen Kategorien gesendet. Der zweite Beacon wird nur berücksichtigt, wenn auch der zweite Chat aktiviert und verbunden ist.
### Intervall und Timer-Verhalten
Das Intervall wird in ganzen Minuten angegeben. Der kleinste zulässige Wert ist eine Minute.
Nach dem Aufbau der Chat-Verbindung prüft KST4Contest die Beacons erstmals nach ungefähr zehn Sekunden. Anschließend gilt das eingestellte Intervall. Wird der Wert während einer laufenden Verbindung geändert, beginnt der Countdown mit dem neuen Intervall erneut. Die Änderung selbst löst keine sofortige Nachricht aus.
### Nachrichtentext und Variablen
Ein Beacon darf nach der Variablenauflösung höchstens 120 Zeichen enthalten. KST4Contest prüft deshalb nicht nur das eingetragene Template, sondern den tatsächlich zu sendenden Text.
Im Beacon können alle [globalen Variablen](de-Makros-und-Variablen#variablen-im-beacon) verwendet werden, beispielsweise:
```text
calling cq at MYQRG, ant MYQTF deg, loc MYLOCATOR
```
Die Variablen werden bei jedem Timer-Lauf neu aufgelöst. Ändert die Logsoftware zwischenzeitlich die in `MYQRG` gespeicherte Frequenz, verwendet bereits der nächste Beacon den neuen Wert.
Stationsbezogene Variablen wie `QRZNAME`, `FIRSTAP` oder `SECONDAP` benötigen dagegen eine ausgewählte Gegenstation. Da ein öffentlicher Beacon keine Gegenstation adressiert, werden diese Variablen im Beacon nicht aufgelöst.
### Wann sollte der Beacon ausgeschaltet werden?
Der Beacon ist nur dann hilfreich, wenn seine QRG-Angabe zum tatsächlichen Betrieb passt. Bleibt er beim Absuchen oder häufigen Wechseln von Frequenzen aktiviert, können andere Stationen auf einer inzwischen falschen Frequenz nach der eigenen Station suchen.
Im Klartext: Solange auf einer festen QRG CQ gerufen wird, spart der Beacon Arbeit. Beim „Schleichen“ über das Band sollte er ausgeschaltet werden.
Änderungen wirken während der laufenden Verbindung. Damit Aktivierung, Texte und Intervall auch nach dem nächsten Programmstart erhalten bleiben, anschließend **Save Settings** verwenden.
---
## Messagehandling Settings (ab v1.25)
Neuer Einstellungsbereich mit folgenden Optionen:
![Automatische Antworten](client_settings_window_messagehandling.png)
- **Auto-Antwort auf alle eingehenden Nachrichten**: Automatische Antwort auf Privatnachrichten konfigurierbar.
- **Auto-Antwort mit eigener CQ-QRG**: Wenn jemand nach der eigenen QRG fragt, antwortet KST4Contest automatisch mit dem Inhalt der `MYQRG`-Variable.
- **Standard-Filter für das Userinfo-Fenster**: Voreingestellter Nachrichtenfilter für das Stationsinfo-Fenster konfigurierbar *(für Gianluca :-) )*.
Die wichtigste Anwendung der allgemeinen automatischen Antwort betrifft Stationen, die zwar im ON4KST-Chat eingeloggt sind, den laufenden Contest aber nicht mitfunken. Gerade während größerer Contests werden Sked-Anfragen teilweise unkoordiniert und in großer Zahl an eingeloggte Stationen verteilt, ohne vorher zu prüfen, ob sie überhaupt teilnehmen. Die Empfänger müssten sonst immer wieder dieselbe Absage schreiben.
KST4Contest kann darauf mit einem vorher festgelegten Text reagieren. Davon getrennt steht eine gezielte QRG-Auskunft zur Verfügung. Beide Funktionen können unabhängig voneinander aktiviert werden.
### Allgemeine automatische Antwort
**Enable automatic reply to all private messages** beantwortet eingehende Privatnachrichten mit dem Text im Feld rechts daneben. Es gibt einen gemeinsamen Text für beide Chat-Kategorien. Die beim Eingeben verwendete Groß- und Kleinschreibung bleibt erhalten.
Eine zweckmäßige Nachricht ist beispielsweise:
```text
Sri, I am not taking part in this contest. No skeds.
```
Die eingegangene Privatnachricht bleibt sichtbar. Die Funktion blockiert oder verwirft keine Anfrage, sondern erspart lediglich die wiederholte manuelle Antwort.
Die Antwort wird in derselben Chat-Kategorie gesendet, in der die Privatnachricht eingegangen ist. Das ist bei einem parallelen Login in zwei Kategorien entscheidend: Eine Nachricht aus dem Microwave-Chat darf nicht versehentlich im VHF/UHF-Chat beantwortet werden.
### Automatische QRG-Antwort
**Enable automatic QRG replies** reagiert auf typische QRG-Anfragen. Die Erkennung unterscheidet nicht zwischen Groß- und Kleinschreibung und sucht nach folgenden Textbestandteilen:
```text
ur qrg?
your qrg?
qrg?
freq?
pse qrg
```
Die Antwort enthält nur die QRG der Kategorie, in der die Anfrage eingegangen ist:
| Eingegangene Privatnachricht | Verwendete QRG |
|---|---|
| Hauptkategorie | aktuelle QRG der Hauptkategorie |
| zweite Chat-Kategorie | aktuelle QRG der zweiten Kategorie |
Die Werte stammen aus denselben QRG-Feldern, die auch von `MYQRG` und `SECONDQRG` verwendet werden. Die Haupt-QRG kann manuell eingetragen oder durch die [TRX-Synchronisation](#trx-sync-einstellungen) aktualisiert werden. Für die zweite Kategorie wird der dort konfigurierte beziehungsweise manuell eingetragene Wert verwendet.
Sind die allgemeine und die QRG-bezogene Antwort gleichzeitig aktiviert, hat die QRG-Antwort Vorrang. Eine erkannte QRG-Anfrage erzeugt daher nicht zusätzlich den allgemeinen Antworttext.
### Schutz vor wiederholten Antworten
Jede automatisch erzeugte Nachricht trägt das feste Präfix:
```text
[KST4C Automsg]
```
Die allgemeine und die QRG-bezogene Antwort reagieren nicht auf Nachrichten, die dieses Präfix bereits enthalten. Dadurch beantworten sich zwei entsprechend arbeitende Clients nicht gegenseitig in einer Schleife.
Zusätzlich gilt eine gemeinsame Sperrzeit von zwei Minuten für beide Antwortarten. Die Sperre wird getrennt je Rufzeichen und Chat-Kategorie geführt. Hat eine Station gerade in der Hauptkategorie eine automatische Antwort erhalten, kann sie deshalb weiterhin eine Antwort in der zweiten Kategorie erhalten. Weitere Nachrichten derselben Station in derselben Kategorie lösen während der folgenden zwei Minuten dagegen keine neue automatische Antwort aus.
Die Sperrzeit beginnt nur, wenn KST4Contest tatsächlich eine Antwort sendet.
> **Hinweis**: Der Antworttext sollte den tatsächlichen Status eindeutig benennen. Wer den Contest nur beobachtet und keine Skeds fahren möchte, sollte genau das mitteilen. Eine vage Nachricht erzeugt im Zweifel nur die nächste Rückfrage und damit exakt die Arbeit, welche die Funktion vermeiden soll.
Änderungen wirken während der laufenden Verbindung. Damit Aktivierung und Text nach dem nächsten Programmstart erhalten bleiben, anschließend **Save Settings** verwenden.
Weitere Hintergründe: [Automatische Antworten auf Privatnachrichten](de-Funktionen#automatische-antworten-auf-privatnachrichten-ab-v125).
---
## Win-Test-Netzwerk-Listener (ab v1.31)
Dedizierter Empfänger für Win-Test-spezifische UDP-Pakete. Ermöglicht:
Der Win-Test-Netzwerk-Listener verarbeitet das native Win-Test-UDP-Protokoll. Er ist vom allgemeinen QSO-UDP-Listener auf Port `12060` unabhängig und übernimmt drei Aufgaben:
- **Log-Synchronisation**: Gearbeitete Stationen werden aus Win-Test übernommen und in der Benutzerliste markiert.
- **Frequenz-Auswertung**: Die aktuelle TRX-Frequenz aus Win-Test befüllt die `MYQRG`-Variable.
- **Sked-Übergabe (SKED Push)**: Skeds aus KST4Contest werden via UDP direkt an Win-Test übergeben. Der UDP-Broadcast-Standardport von Win-Test (9871) wird verwendet.
- QSOs einschließlich Band- und Locatorinformation auswerten,
- STATUS-Pakete für die eigene QRG verarbeiten und
- Skeds an das Win-Test-Netzwerk übergeben.
Einstellungen:
- **Aktivieren/Deaktivieren**: Checkbox in den Preferences (ab v1.40).
- **Port**: Konfigurierbarer UDP-Port für den Win-Test-Listener.
- **Sked-UDP-Adresse und Port**: Zieladresse und Port für die SKED-Übergabe an Win-Test.
### Einstellungen unter Log sync
> **Hinweis**: Der Win-Test-Listener ist ein **zusätzlicher** Listener der Standard-QSO-UDP-Broadcast-Listener auf Port 12060 bleibt davon unabhängig.
| Einstellung | Funktion |
|---|---|
| **Receive Win-Test network based UDP log messages** | Aktiviert den Win-Test-Netzwerk-Listener. Bei aktiviertem Listener wird nach **Create sked** auch die Sked-Übergabe versucht. |
| **UDP-Port for Win-Test listener** | Port des Win-Test-Netzwerks. Standard ist `9871`. Der Port wird auch für die Sked-Übergabe verwendet. |
| **KST station name in Win-Test network (src of SKED packets)** | Stationsname, unter dem KST4Contest die Sked-Pakete sendet. In einem Netzwerk mit mehreren Clients sollte ein eindeutiger Name verwendet werden. |
| **Win-Test network broadcast address** | Zieladresse für ausgehende Win-Test-Netzwerkpakete. Bei lokalem Netzwerkbetrieb muss hier eine vom Win-Test-Rechner erreichbare Broadcast-Adresse eingetragen sein. |
Die Broadcast-Adresse ist konfigurierbar, weil `255.255.255.255` nicht in jedem Stationsnetz und nicht über jede Netzwerkschnittstelle zuverlässig weitergeleitet wird. Bei mehreren Rechnern kann stattdessen die zum Stationsnetz gehörende gerichtete Broadcast-Adresse erforderlich sein.
### Einstellungen unter TRX sync
| Einstellung | Funktion |
|---|---|
| **Win-Test STATUS QRG Sync** | Übernimmt die aktuelle Frequenz aus Win-Test-STATUS-Paketen als eigene QRG. |
| **Use pass frequency from Win-Test STATUS** | Verwendet die übertragene Pass-Frequenz anstelle der normalen TRX-QRG. |
| **Win-Test station name filter** | Verarbeitet nur STATUS-Pakete der angegebenen Win-Test-Station. Ein leeres Feld akzeptiert alle Stationsnamen. |
Der Stationsfilter ist insbesondere bei mehreren Win-Test-Clients sinnvoll. Ohne Filter kann die zuletzt eingegangene STATUS-Meldung eines anderen Arbeitsplatzes die eigene QRG in KST4Contest überschreiben.
### Sked-Übergabe
Für die Sked-Übergabe gibt es keinen davon getrennten internen Sked-Modus. Ist der Listener aktiviert, versucht **Create sked** zusätzlich zur internen Anlage die Übertragung an Win-Test.
KST4Contest sendet nur dann ein `ADDSKED`-Paket, wenn eine QRG ermittelt wurde, die zum ausdrücklich ausgewählten Band gehört. Kann keine passende QRG gefunden werden, bleibt der interne Sked bestehen und die Win-Test-Übergabe wird ausgelassen.
Die Auswahl `SSB` oder `CW` erfolgt direkt im Further-Info-Bereich beim Anlegen des Skeds. Eine automatische Mode-Ableitung wird nicht verwendet.
Nach Änderungen **Save Settings** verwenden, damit Port, Stationsname, Broadcast-Adresse und TRX-Optionen beim nächsten Programmstart wiederhergestellt werden.
Datenbehandlung und QRG-Auswahl: [Log-Synchronisation Win-Test](de-Log-Synchronisation#win-test)
---
## PSTRotator-Einstellungen (ab v1.31)
@@ -229,14 +407,37 @@ Einstellungen:
---
## GUI Settings: Hinweise in den Bandspalten
Im Reiter **GUI** lassen sich zwei Zusatzinformationen der Bandspalten ein- oder ausblenden:
- **Show "o" in band columns …** zeigt ein `o`, wenn das vierstellige Großfeld auf dem betreffenden Band bereits gearbeitet wurde. Das Abschalten entfernt keine Daten aus der Datenbank; nur die zusätzliche Anzeige in den Bandspalten wird ausgeblendet. `wkdany` bleibt davon unberührt.
- **Show "a" in band columns …** unterscheidet ein vollständig neues Rufzeichen von einer Bandmöglichkeit mit einem bereits auf einem anderen Band gearbeiteten Rufzeichen. Ist die Option ausgeschaltet, werden beide Fälle als `B+` dargestellt. Die Bandherleitung selbst ändert sich dadurch nicht.
Änderungen werden in der laufenden Benutzeroberfläche unmittelbar sichtbar. Damit sie nach dem nächsten Programmstart erhalten bleiben, anschließend **Save Settings** verwenden.
![GUI-Einstellungen für die Hinweise in den Bandspalten](client_settings_window_gui.png)
---
## Worked Station Database Settings (Gearbeitete-Stationen-Datenbank)
Die interne Worked-Datenbank enthält:
Die interne SQLite-Datenbank speichert die contestbezogenen Zustände unabhängig von der Datenbank des Logprogramms:
- Worked-Status aller Stationen (pro Band)
- NOT-QRV-Tags (seit v1.2)
- globaler Worked-Status eines Rufzeichens,
- Worked-Status pro Band,
- manuell gesetzte NOT-QRV-Tags pro Band und
- gearbeitete vierstellige Großfelder pro Band.
**Ab v1.40**: Einträge haben eine automatische Lebensdauer von **3 Tagen** ein manuelles Zurücksetzen vor jedem Contest ist nicht mehr zwingend notwendig. Für ein vollständiges Reset kann trotzdem die Schaltfläche **„Reinitialize"** verwendet werden.
Als Schlüssel wird das normalisierte Rufzeichen ohne sichtbare Chat-Klammern oder Kategorieformatierung verwendet. Dadurch können aktive Varianten desselben Rufzeichens konsistent ausgewertet werden.
Worked- und NOT-QRV-Informationen laufen drei Tage nach ihrer letzten Änderung automatisch ab. Gespeicherte Großfelder laufen drei Tage nach dem zugehörigen Logeintrag ab. Ein manuelles Zurücksetzen vor jedem Contest ist deshalb normalerweise nicht erforderlich.
Die Schaltfläche **Reset worked, NOT-QRV and grid data...** entfernt sämtliche Worked-Markierungen, NOT-QRV-Tags und gespeicherten Großfelder. Vor dem Reset erscheint eine Sicherheitsabfrage. Die bekannten Rufzeichenzeilen bleiben erhalten; zurückgesetzt werden nur die contestbezogenen Zustände.
Ein Reset ist sinnvoll, wenn bewusst mit einem leeren Conteststand begonnen werden soll oder Testdaten eingelesen wurden. Als tägliche Wartungsmaßnahme ist er nicht vorgesehen.
Anzeige und Herleitung: [Gearbeitete Rufzeichen, neue Bänder und neue Großfelder](de-Funktionen#gearbeitete-rufzeichen-neue-bänder-und-neue-großfelder).
---
+90 -33
View File
@@ -2,7 +2,7 @@
> 🇬🇧 [English version](en-Log-Sync) | 🇩🇪 Du liest gerade die deutsche Version
KST4Contest markiert gearbeitete Stationen automatisch in der Chat-Benutzerliste. Dafür gibt es zwei grundlegende Methoden:
KST4Contest übernimmt gearbeitete Stationen aus dem Logprogramm und stellt daraus den globalen Worked-Status, bandbezogene Worked-Markierungen und sofern ein Locator übertragen wurde gearbeitete Großfelder bereit. Dafür gibt es drei Wege: den dateibasierten Simplelogfile-Interpreter, den allgemeinen QSO-UDP-Listener und den eigenen Win-Test-Netzwerk-Listener.
---
@@ -10,24 +10,25 @@ KST4Contest markiert gearbeitete Stationen automatisch in der Chat-Benutzerliste
## Methode 1: Universal File Based Callsign Interpreter (Simplelogfile)
KST4Contest liest eine Log-Datei und sucht mittels regulärem Ausdruck nach Rufzeichen-Mustern. Dabei werden auch binäre Logdateien unterstützt unlesbarer Binärinhalt wird einfach ignoriert.
KST4Contest liest eine Logdatei und sucht mit einem konfigurierbaren regulären Ausdruck nach Rufzeichen. Die Datei wird ausschließlich gelesen und nicht verändert. Auch binäre Logdateien können verwendet werden; nicht als Text interpretierbare Inhalte werden übersprungen.
**Vorteil**: Funktioniert mit nahezu jedem Logprogramm, das eine Datei schreibt.
**Nachteil**: Keine Bandinformation möglich es wird nur „gearbeitet" markiert, nicht auf welchem Band.
Der Vorteil liegt in der breiten Kompatibilität: Die Funktion benötigt keine besondere Netzwerkschnittstelle des Logprogramms.
Pfad der Log-Datei in den Preferences eintragen. Die Datei wird nur gelesen, nie verändert (read-only).
Die Grenze ist ebenso eindeutig: Aus einem reinen Rufzeichentreffer lassen sich weder Band noch Locator zuverlässig ableiten. Der Simplelogfile-Interpreter kann deshalb nur den globalen Worked-Status setzen. Er erzeugt keine bandbezogene `X`-Markierung, kein Worked-Großfeld und keine belastbare Grundlage für den Band-Upgrade-Hinweis nach einem Logeintrag.
> **Tipp**: Die Simplelogfile-Funktion kann auch genutzt werden, um Stationen zu markieren, die definitiv nicht erreichbar sind (z. B. eigene Notizen). Das wird in einer späteren Version durch ein besseres Tagging-System ersetzt.
Den Pfad der Logdatei und den regulären Ausdruck im Reiter **Log sync** eintragen. Für bandbezogene Auswertungen sollte nach Möglichkeit eine der Netzwerkschnittstellen verwendet werden.
---
## Methode 2: Netzwerk-Listener (UDP-Broadcast) Empfohlen
## Methode 2: Netzwerk-Listener für QSO-UDP-Pakete empfohlen
Das Logprogramm sendet beim Speichern eines QSOs ein UDP-Paket an die Broadcast-Adresse des Heimnetzwerks. KST4Contest empfängt dieses Paket und markiert die Station inklusive **Bandinformation** in der internen SQLite-Datenbank.
UCXLog, QARTest, N1MM+ und DXLog.net können beim Speichern eines QSOs ein UDP-Paket senden. KST4Contest empfängt diese Pakete standardmäßig auf Port `12060` und übernimmt das Rufzeichen sowie die enthaltenen Band- und Locatorinformationen.
> **Wichtig**: KST4Contest muss **parallel zum Logprogramm laufen**. QSOs, die während einer Abwesenheit von KST4Contest geloggt werden, werden nicht erfasst außer bei QARTest (kann das komplette Log senden).
Liegt eine Bandinformation vor, wird das Rufzeichen für dieses Band als gearbeitet markiert. Enthält das Paket zusätzlich einen gültigen Locator, speichert KST4Contest dessen vierstelliges Großfeld für das betreffende Band. Fehlende Informationen werden nicht aus anderen Feldern geraten.
**Standard UDP-Port**: 12060 (entspricht dem Standard der meisten Logprogramme)
KST4Contest muss zum Zeitpunkt der Übertragung laufen. Einige Logprogramme können jedoch das vorhandene Log erneut senden: QARTest bietet dafür **Invia log completo**; DXLog.net sendet beim Broadcast des vollständigen Logs `contactreplace`-Pakete, die KST4Contest ebenfalls verarbeitet.
**Standardport:** `12060`
---
@@ -81,34 +82,80 @@ Für den integrierten DX-Cluster-Server: N1MM+ als DX-Cluster-Client konfigurier
- IP des KST4Contest-Computers eintragen (grün markierte Felder)
- Port: 12060
Beim Broadcast des vollständigen Logbuchs verwendet DXLog.net `contactreplace` anstelle von `contactinfo`. KST4Contest verarbeitet beide Pakettypen. Damit können auch ältere QSOs übernommen werden, wenn der vollständige Broadcast ausgelöst wird, während KST4Contest läuft.
### Win-Test
Win-Test wird mit einem dedizierten UDP-Netzwerk-Listener unterstützt, der das native Win-Test Netzwerkprotokoll versteht.
Win-Test wird über einen eigenen UDP-Listener für das native Win-Test-Netzwerkprotokoll angebunden. Dieser Listener ist vom allgemeinen QSO-UDP-Listener auf Port `12060` unabhängig.
**Vorteile der Win-Test Integration:**
- Automatische QSO-Synchronisation zur Markierung gearbeiteter Stationen.
- **Sked-Übergabe (ADDSKED):** Über den Button "Create sked" im Stationsinfo-Panel wird nicht nur in KST4Contest ein Sked angelegt, sondern dieser auch *direkt per UDP an das Win-Test Netzwerk als ADDSKED-Paket gesendet* automatisch, sobald der Listener aktiv ist.
- Es kann zwischen den Sked-Modi "AUTO", "SSB" oder "CW" gewählt werden.
- **Automatische QRG-Auflösung für SKEDs:** KST4Contest wählt die Sked-Frequenz intelligent:
1. Hat die Gegenstation in einer Chat-Nachricht ihre QRG genannt, wird diese verwendet.
2. Sonst wird die eigene aktuelle QRG verwendet (aus Win-Test STATUS oder manueller Eingabe).
#### QSO- und Worked-Synchronisation
**Einstellungen im Reiter „Log-Synchronisation":**
- `Receive Win-Test network based UDP log messages` aktivieren.
- `UDP-Port for Win-Test listener` (Standard: 9871).
- `KST station name in Win-Test network (src of SKED packets)`: Legt fest, unter welchem Stationsnamen KST4Contest im WT-Netzwerk auftritt (z.B. "KST").
- `Win-Test network broadcast address`: Wird i.d.R. automatisch erkannt; erforderlich für das Senden von Sked-Paketen.
Bei einem neuen QSO übernimmt KST4Contest:
**Einstellungen im Reiter „TRX-Synchronisation":**
- `Win-Test STATUS QRG Sync`: Wenn aktiviert, übernimmt KST4Contest die aktuelle Transceiverfrequenz aus dem Win-Test STATUS-Paket als eigene QRG (MYQRG).
- `Use pass frequency from Win-Test STATUS`: Statt der eigenen TRX-QRG wird die im STATUS-Paket enthaltene Pass-Frequenz als MYQRG verwendet (für Multi-Op-Setups, bei denen mit einer Pass-QRG gearbeitet wird).
- `Win-Test station name filter`: Wird hier ein Name eingetragen (z.B. "STN1"), verarbeitet KST4Contest nur Pakete dieser Win-Test-Instanz. Leer lassen, um alle zu akzeptieren.
- das geloggte Rufzeichen,
- die native Win-Test-Band-ID und
- einen gültigen Locator, sofern er im Paket enthalten ist.
**Einstellungen in Win-Test:**
- Das Netzwerk in Win-Test muss aktiv sein.
- Win-Test muss so konfiguriert sein, dass es seine Broadcasts an den entsprechenden Port (Standard 9871) sendet bzw. empfängt.
Die Band-IDs für 50 und 70 MHz werden ebenso verarbeitet wie die VHF-, UHF- und SHF-Bänder. Das Rufzeichen wird global und auf dem erkannten Band als gearbeitet markiert. Liegt zusätzlich ein Locator vor, wird dessen vierstelliges Großfeld für dieses Band gespeichert.
Die Daten werden in derselben internen Datenbank abgelegt wie Worked-Informationen aus den übrigen QSO-UDP-Schnittstellen und nach einem Neustart wiederhergestellt.
#### Skeds an Win-Test übergeben
Mit **Create sked** wird zunächst ein interner KST4Contest-Sked angelegt. Ist der Win-Test-Netzwerk-Listener aktiviert, versucht KST4Contest anschließend automatisch, den Sked als `ADDSKED` an das Win-Test-Netzwerk zu übertragen.
Die QRG wird in folgender Reihenfolge bestimmt:
1. KST4Contest sucht die neueste, höchstens 30 Minuten alte QRG der Gegenstation auf dem ausdrücklich ausgewählten Band. Dabei werden aktive Varianten desselben Basisrufzeichens gemeinsam ausgewertet.
2. Fehlt eine solche QRG, wird die eigene QRG der Chat-Kategorie geprüft, in der der Sked angelegt wurde. Sie wird nur verwendet, wenn sie sich auswerten lässt und tatsächlich zum ausgewählten Band gehört.
3. Kann auf keinem dieser Wege eine passende QRG ermittelt werden, wird kein `ADDSKED` gesendet.
Eine feste Ersatzfrequenz wie `144.300` wird bewusst nicht verwendet. Eine technisch erfolgreiche Übergabe mit falschem Band oder falscher QRG wäre im Contestbetrieb schlechter als eine sichtbar ausgelassene Übergabe.
Der interne Sked bleibt in jedem Fall erhalten. Das gilt auch bei einer ungültigen Broadcast-Adresse, einem Netzwerkfehler oder einem nicht erreichbaren Win-Test-Client.
#### Behandlung von KST-Rufzeichensuffixen
KST-Suffixe kennzeichnen häufig den verwendeten Chat-Login oder ein Band. Sie gehören nicht in jedem Fall zum Logrufzeichen. Für Win-Test entfernt KST4Contest deshalb einen mit `-` abgetrennten KST-Suffix, erhält aber portable und internationale Rufzeichenbestandteile:
| Rufzeichen im KST-Chat | Übergabe an Win-Test |
|---|---|
| `DN9APW-2` | `DN9APW` |
| `9A0BB-70` | `9A0BB` |
| `EA5/G8MBI/P-70` | `EA5/G8MBI/P` |
| `DN9APW-2/P` | `DN9APW/P` |
Innerhalb von KST4Contest bleibt das vollständige Rufzeichen erhalten. Timeline, Reminder-PMs und Chat-Kategorie beziehen sich weiterhin auf den konkret ausgewählten Login.
#### Mode, Zeitpunkt und Notizen
Der Mode wird beim Anlegen des Skeds ausdrücklich als `SSB` oder `CW` gewählt. Eine automatische Ableitung aus der QRG findet nicht statt, weil eine begrenzte Liste angenommener Bandsegmente nicht alle unterstützten VHF-, UHF- und SHF-Bänder zuverlässig abbilden kann.
KST4Contest überträgt den tatsächlichen Sked-Zeitpunkt ohne einen zusätzlichen Minutenversatz. Die Notizen enthalten soweit bekannt Locator und QTF sowie den Hinweis, dass der Sked über KST4Contest angelegt wurde.
Für die Übergabe sendet KST4Contest die Win-Test-Pakete `LOCKSKED`, `ADDSKED` und `UNLOCKSKED`.
![Von KST4Contest an Win-Test übergebener Sked](wintest_sked_handover.png)
#### Einstellungen
Im Reiter **Log sync**:
- `Receive Win-Test network based UDP log messages`
- `UDP-Port for Win-Test listener`, standardmäßig `9871`
- `KST station name in Win-Test network (src of SKED packets)`
- `Win-Test network broadcast address`
Im Reiter **TRX sync**:
- `Win-Test STATUS QRG Sync`
- `Use pass frequency from Win-Test STATUS`
- `Win-Test station name filter`
Das Win-Test-Netzwerk muss in Win-Test aktiviert sein. Bei mehreren Computern muss die Broadcast-Adresse das betreffende lokale Netzwerk erreichen. Der Stationsname sollte die sendende KST4Contest-Instanz innerhalb des Win-Test-Netzwerks eindeutig erkennen lassen.
Ausführliche Beschreibung der Einstellungen: [Win-Test-Netzwerk-Listener](de-Konfiguration#win-test-netzwerk-listener-ab-v131)
---
## TRX-Frequenz-Synchronisation
@@ -144,6 +191,16 @@ Für DM5M-typische Setups (2 Radios, 2 Computer, eine KST4Contest-Instanz oder z
## Interne Datenbank
KST4Contest speichert die Worked-Information in einer internen **SQLite-Datenbank**. Diese ist von der Logprogramm-Datenbank unabhängig und wird nur über den UDP-Broadcast befüllt.
KST4Contest speichert Worked-, NOT-QRV- und Großfeldinformationen in einer eigenen SQLite-Datenbank. Sie ist von der Datenbank des Logprogramms unabhängig.
Vor jedem neuen Contest: Datenbank zurücksetzen! → [Konfiguration Worked Station Database Settings](Konfiguration#worked-station-database-settings)
Die Datenquellen liefern unterschiedlich genaue Informationen:
| Quelle | Rufzeichen global | Bandbezogen | Großfeld |
|---|---:|---:|---:|
| Simplelogfile | ja | nein | nein |
| QSO-UDP-Listener | ja | ja, wenn im Paket enthalten | ja, wenn Band und Locator enthalten sind |
| Win-Test-Netzwerk-Listener | ja | ja | ja, wenn ein Locator enthalten ist |
Die Daten werden beim Programmstart wieder geladen und bei neuen Logeinträgen während des Betriebs aktualisiert. Sie laufen nach drei Tagen automatisch ab. Ein Reset vor jedem Contest ist daher normalerweise nicht erforderlich.
Ein vollständiger manueller Reset entfernt Worked-Markierungen, NOT-QRV-Tags und Worked-Großfelder gemeinsam. Weitere Einzelheiten: [Worked Station Database Settings](de-Konfiguration#worked-station-database-settings-gearbeitete-stationen-datenbank).
+19 -3
View File
@@ -138,18 +138,34 @@ Wird durch die aktuelle Antennenrichtung in Worten ersetzt (z. B. `north`, `nort
---
## Variablen im Beacon
## Variablen im Beacon
Alle Variablen können auch im **automatischen Beacon** (Intervall-Nachrichten) verwendet werden. Empfohlene Beacon-Konfiguration:
Ein öffentlicher Beacon besitzt keine ausgewählte Gegenstation. Deshalb können hier ausschließlich Variablen verwendet werden, die nur von der eigenen Station und ihrer aktuellen Konfiguration abhängen:
| Variable | Wert im Beacon |
|---|---|
| `MYQRG` | aktuelle QRG der ersten Chat-Kategorie |
| `MYQRGSHORT` | auf sieben Zeichen gekürzte QRG der ersten Kategorie |
| `SECONDQRG` | aktuelle QRG der zweiten Chat-Kategorie |
| `MYLOCATOR` | eigener vollständiger Locator |
| `MYLOCATORSHORT` | eigener vierstelliger Locator |
| `MYCALL` | eigenes Rufzeichen |
| `MYQTF` | aktuelle Antennenrichtung |
`QRZNAME`, `FIRSTAP` und `SECONDAP` benötigen eine ausgewählte Station. In einem öffentlichen Beacon werden sie daher nicht aufgelöst.
Eine zweckmäßige Konfiguration ist beispielsweise:
```
calling cq at MYQRG, loc MYLOCATOR, GL all!
```
Da KST4Contest QRG-Daten automatisch aus Chat-Nachrichten ausliest: Wenn andere Stationen ebenfalls KST4Contest nutzen, sehen sie die eigene QRG sofort in der QRG-Spalte der Benutzerliste.
Die globalen Variablen werden bei jedem Timer-Lauf neu ausgewertet. Dadurch kann eine vom Logprogramm aktualisierte QRG bereits in der nächsten Beacon-Nachricht erscheinen.
Der vollständig aufgelöste Nachrichtentext darf höchstens 120 Zeichen enthalten. Weitere Angaben zum gemeinsamen Intervall und zum Verhalten beider Chat-Kategorien stehen unter [Konfiguration Beacon Settings](de-Konfiguration#beacon-settings-automatischer-beacon).
---
## Beispiel-Workflow mit Makros im Contest
1. Station in der Benutzerliste auswählen → Rufzeichen ist nun vorausgewählt.
Binary file not shown.

After

Width:  |  Height:  |  Size: 961 KiB

+133 -14
View File
@@ -25,7 +25,18 @@ Enter your own callsign and Maidenhead locator (6 characters, e.g., `JN49IJ`). T
### Active Bands
Use the **"my station uses band"** checkboxes to select the active bands. Buttons and table rows will only appear in the user interface for selected bands. The software must be restarted after making changes.
The **My station uses ** checkboxes define the bands available in the current local station setup. Supported choices are 50 MHz, 70 MHz, 144 MHz, 432 MHz, 1296 MHz, 2320 MHz, 3400 MHz, 5760 MHz and 10 GHz.
This selection controls more than the visible band columns. It is also used for:
- the per-band Worked and NOT-QRV filters,
- the NOT-QRV controls visible in the **Further Info** panel,
- the `a` and `B+` band-opportunity calculation,
- the **New bands** filter,
- the band-upgrade hint after a log entry, and
- band-specific priority and Reachability functions.
After a change, click **Save Settings** and restart KST4Contest. Band columns and several related controls are created while the user interface is being built and are therefore not added or removed completely during the current session.
### Antenna Beamwidth
@@ -87,12 +98,71 @@ Configuration of the interface to AirScout for aircraft scatter detection. Detai
## Notification Settings
![Notifications, DX cluster output and QSO monitoring](client_settings_window_notification.png)
Three notification types are available:
1. **Simple sounds**: TADA sound for incoming messages, tick for sked direction detection, etc.
2. **CW announcement**: The callsign of a station sending a private message is output as a CW signal.
3. **Phonetic announcement**: The callsign is pronounced phonetically.
### Fallback Band for Relative QRG Detection
The **Fallback band for relative QRG detection** dropdown selects the band used when a relative QRG cannot be assigned to a recent station-specific band context.
Only band prefixes supported by the frequency parser are available:
```text
50 MHz
70 MHz
144 MHz
432 MHz
1296 MHz
2320 MHz
3400 MHz
5760 MHz
10368 MHz (10G)
24048 MHz (24G)
```
The dropdown is neither a filter nor an override for complete frequencies. `432.088` is recognised as a frequency in the 432 MHz band regardless of the selection. The fallback is needed for relative values such as `.205`, `,205` or `qrg 205`.
Before using the fallback, KST4Contest checks the sender's recent band context. If a complete frequency has been detected for the same station during the previous 30 minutes, that band takes precedence. A fallback setting of `144 MHz` therefore still turns `.100` into `432.100 MHz` if the station mentioned `432.088` shortly before.
Although the setting is located in the Notification tab, it affects the general QRG parser. It therefore influences the QRG column, detected active bands, priority calculations, band-upgrade hints and other functions which use a known station frequency not only DX cluster spots.
### Band Upgrade Hint after a Log Entry
After receiving a log entry from UCXLog or Win-Test, KST4Contest can check whether the station which has just been worked still offers another common and unworked band.
The check uses the same derivation as the `a` and `B+` display:
1. the bands enabled in the local station settings,
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.
Active chat variants of the same normalised callsign are evaluated together. NOT-QRV takes precedence over an automatically detected QRG or band designator.
If at least one common and unworked band remains, the main window displays a blinking **BAND+** hint for approximately twelve seconds. The callsign and remaining bands are included in the button text; the tooltip contains the complete derivation. If general notification sounds are enabled, KST4Contest also plays a short sound.
The two options serve different purposes:
- **Blink + sound …** enables the hint after a matching log entry.
- **Priority boost …** additionally raises the score of stations which have already been worked on at least one band but still offer another common and unworked band.
The Priority Boost is only one factor in the complete calculation. Distance, antenna direction, recent activity, AirScout data, skeds and negative hints may still change the final order. Enabling the option therefore guarantees neither a particular score nor a particular position in the priority list.
The other score weights currently have no separate user-interface controls. Several existing settings nevertheless provide input data for the calculation, particularly the [enabled bands](#enabled-bands), [antenna beamwidth](#antenna-beamwidth), [default maximum QRB](#default-maximum-qrb) and [AirScout settings](#airscout-settings).
The complete calculation is described under [Priority Score and Priority List](en-Features#priority-score-and-priority-list-from-v140).
The hint requires a log-synchronisation source which provides band information. The file-based callsign interpreter sees callsigns only and cannot reliably identify the band of the QSO which has just been logged.
Further explanation: [Band Upgrade Hint after a Log Entry](en-Features#band-upgrade-hint-after-a-log-entry).
---
## Shortcut Settings
@@ -135,18 +205,44 @@ New settings section with the following options:
## Win-Test Network Listener (from v1.31)
A dedicated listener for Win-Test-specific UDP packets. Enables:
The Win-Test network listener processes the native Win-Test UDP protocol. It is independent of the general QSO UDP listener on port `12060` and has three separate tasks:
- **Log synchronisation**: Worked stations are retrieved from Win-Test and marked in the user list.
- **Frequency parsing**: The current TRX frequency from Win-Test populates the `MYQRG` variable.
- **Sked handover (SKED push)**: Skeds from KST4Contest are passed directly to Win-Test via UDP. Win-Test's default UDP broadcast port (9871) is used.
- processing QSOs including band and locator information,
- processing STATUS packets for the local QRG, and
- handing skeds over to the Win-Test network.
Settings:
- **Enable/Disable**: Checkbox in Preferences (from v1.40).
- **Port**: Configurable UDP port for the Win-Test listener.
- **Sked UDP address and port**: Target address and port for SKED handover to Win-Test.
### Log sync settings
> **Note**: The Win-Test listener is an **additional** listener the standard QSO UDP broadcast listener on port 12060 remains independent.
| Setting | Function |
|---|---|
| **Receive Win-Test network based UDP log messages** | Enables the Win-Test network listener. When the listener is enabled, pressing **Create sked** also attempts the Win-Test handover. |
| **UDP-Port for Win-Test listener** | Port used by the Win-Test network. The default is `9871`. The same port is used for the sked handover. |
| **KST station name in Win-Test network (src of SKED packets)** | Station name used by KST4Contest when sending sked packets. A unique name should be used in a network containing several clients. |
| **Win-Test network broadcast address** | Destination address for outgoing Win-Test network packets. In a local network, the address must be reachable by the Win-Test computer. |
The broadcast address is configurable because `255.255.255.255` is not forwarded reliably through every station network or network interface. In a multi-computer setup, the directed broadcast address belonging to the station network may be required instead.
### TRX sync settings
| Setting | Function |
|---|---|
| **Win-Test STATUS QRG Sync** | Takes the current frequency from Win-Test STATUS packets and uses it as the local QRG. |
| **Use pass frequency from Win-Test STATUS** | Uses the transmitted pass frequency instead of the normal TRX QRG. |
| **Win-Test station name filter** | Only processes STATUS packets from the specified Win-Test station. An empty field accepts every station name. |
The station filter is particularly useful when several Win-Test clients are active. Without a filter, the most recently received STATUS packet from another operating position can overwrite the local QRG in KST4Contest.
### Sked handover
There is no separate internal sked mode for the Win-Test handover. When the listener is enabled, **Create sked** attempts the Win-Test transfer in addition to creating the internal sked.
KST4Contest only sends an `ADDSKED` packet when it can determine a QRG which belongs to the explicitly selected band. If no matching QRG is available, the internal sked remains intact and the Win-Test handover is omitted.
`SSB` or `CW` is selected directly in the Further Info section when the sked is created. No automatic mode inference is used.
Click **Save Settings** after making changes so that the port, station name, broadcast address and TRX options are restored at the next start.
Data handling and QRG selection: [Log Synchronisation Win-Test](en-Log-Sync#win-test)
---
@@ -174,14 +270,37 @@ Use case: Keep track of important stations (e.g. DX expeditions or trusted conte
---
## GUI Settings: Band-Column Hints
Two optional additions to the band columns can be enabled or disabled in the **GUI** tab:
- **Show "o" in band columns …** displays an `o` if the four-character grid square has already been worked on the relevant band. Disabling the option does not delete any database records; it only hides the additional indicator in the band columns. `wkdany` is unaffected.
- **Show "a" in band columns …** distinguishes a completely new callsign from a band opportunity involving a callsign already worked elsewhere. When disabled, both cases are displayed as `B+`. The band-opportunity calculation itself remains unchanged.
Changes are reflected in the current user interface immediately. Click **Save Settings** afterwards if they should persist after the next start.
![GUI settings for band-column hints](client_settings_window_gui.png)
---
## Worked Station Database Settings
The internal worked database contains:
The internal SQLite database stores contest-related state independently of the logging application's database:
- Worked status of all stations (per band)
- NOT-QRV tags (since v1.2)
- the global Worked status of a callsign,
- Worked status per band,
- manually assigned NOT-QRV marks per band, and
- worked four-character grid squares per band.
**From v1.40**: Entries have an automatic lifetime of **3 days** manually resetting before each contest is no longer strictly necessary. For a full reset, the **"Reinitialize"** button is still available.
The normalised callsign, without visible chat brackets or category formatting, is used as the key. This allows active variants of the same callsign to be evaluated consistently.
Worked and NOT-QRV information expires automatically three days after its most recent change. Stored grid squares expire three days after the corresponding log entry. A manual reset before every contest is therefore normally unnecessary.
The **Reset worked, NOT-QRV and grid data...** button removes every Worked mark, NOT-QRV mark and stored worked grid square. A confirmation dialog is displayed first. Known callsign rows remain in the database; only the contest-related state is reset.
A reset is useful when you deliberately want to start with an empty contest state or have imported test data. It is not intended as a daily maintenance step.
Display and derivation: [Worked Callsigns, New Bands and New Grid Squares](en-Features#worked-callsigns-new-bands-and-new-grid-squares).
---
+332 -49
View File
@@ -48,26 +48,92 @@ Recognised formats: `144.205`, `432.088`, `.205` (with configured band assumptio
---
## Worked Marking
## Worked Callsigns, New Bands and New Grid Squares
Worked stations are visually marked in the user list per band. Based on [Log Synchronisation](en-Log-Sync) via UDP or Simplelogfile.
KST4Contest distinguishes between three pieces of information which may look similar during a contest but answer different questions:
Reset the database before each contest: [Configuration Worked Station Database Settings](Configuration#worked-station-database-settings).
1. Has this callsign been worked before?
2. Has this callsign been worked on a particular band?
3. Has the four-character Maidenhead grid square already been worked, possibly with a different station?
---
This distinction matters. A callsign already worked on one band may still be useful on another. Conversely, a new callsign may be located in a grid square which is already in the log.
## NOT-QRV Tags (from v1.2)
### Worked information from the log
When a station indicates it is not QRV on a specific band, this can be manually marked:
[Log Synchronisation](en-Log-Sync) imports new QSOs from the logging application. The amount of information available depends on the interface being used:
- The file-based Simplelogfile interpreter detects callsigns only. It can therefore set only the global Worked status.
- The QSO UDP interfaces and the Win-Test network listener can also provide the band.
- If the log packet contains a valid locator, KST4Contest additionally stores the worked four-character grid square for that band.
Missing information is not guessed. A QSO without a locator does not create a worked-grid record, and a Simplelogfile match does not create a band-specific Worked mark.
### Meaning of the band columns
The shared **worked** column contains only the bands enabled under **Station → My station uses …**. Its cells deliberately use short status codes because a full description would leave very little room for the actual user list.
| Display | Meaning |
|---|---|
| `X` | The callsign has been worked on this band. |
| `a` | The station offers this band, the band has not been worked yet, and the callsign has not been worked on any band. |
| `B+` | The station offers this band and it has not been worked yet. The callsign has already been worked on another band. If the separate `a` display is disabled, a completely new callsign is also shown as `B+`. |
| `o` | The station's four-character grid square has already been worked on this band, regardless of callsign. |
| empty | No matching information is available for this band. This does not mean that the station is not QRV. |
The `o` is an independent overlay and can therefore be combined with the other codes. Examples include `Xo`, `ao` and `B+o`. A single `o` means that the grid square has been worked on this band, while the displayed callsign has neither a Worked mark nor a current band opportunity.
![Band-specific Worked status and worked grid squares](worked_band_status.png)
### How is a band opportunity derived?
KST4Contest displays `a` or `B+` only if it can derive an open band opportunity. The calculation combines:
1. the bands enabled for the local station,
2. QRGs detected for the remote station during the previous 30 minutes,
3. explicit band designators in the remote station's name field,
4. stored per-band Worked marks, and
5. manually assigned NOT-QRV marks.
Active chat entries with the same normalised callsign are evaluated together. This is particularly relevant when the station appears in several chat categories or with different visible callsign variants. An explicit band designator in the name field remains useful while the corresponding chat entry is active. A band derived from a detected QRG expires after 30 minutes.
The remaining set contains only bands which are enabled locally, known for the remote station and not yet worked. A manual NOT-QRV mark overrides automatically detected evidence. The chat category alone is not sufficient evidence that an individual station is QRV on a particular band.
The global Worked mark does not decide whether a band opportunity exists. It merely selects `a` or `B+` for the display. The actual opportunity calculation uses per-band Worked information.
### Meaning of `wkdany`
The **wkdany** subcolumn combines the global callsign and grid-square status:
| Display | Meaning |
|---|---|
| empty | Neither the callsign nor the four-character grid square has been worked. |
| `x` | The callsign has been worked on at least one band. |
| `o` | The four-character grid square has been worked on at least one band. |
| `xo` | Both the callsign and the grid square have been worked. |
`wkdany` is deliberately band-independent. The lower-case `x` must therefore not be confused with the upper-case `X` in a band column. The global status is used for the overview and the global **wkd** filter; it is not a substitute for per-band Worked information.
### NOT-QRV marks
If a station reports that it is not QRV on a particular band, mark this in the selected station's **Further Info** panel:
1. Select the station in the user list.
2. Right-click → Set NOT-QRV for the appropriate band.
2. Enable the relevant band under **Not QRV**.
3. Use **tag not qrv all** only if the station should not be requested on any supported band.
These tags are stored in the internal database and persist after a KST4Contest restart. Can be reset via the settings.
The individual NOT-QRV controls are shown for the bands enabled at the local station. **tag not qrv all**, however, marks every supported band, including bands which are not currently visible in the user interface. The state is stored per band under the normalised callsign and propagated to its active chat variants.
**Benefit**: Prevents repeated sked requests on bands where the station is not active saves time for both sides.
![Per-band NOT-QRV marks in the Further Info panel](not_qrv_controls.png)
---
NOT-QRV is a manual correction and therefore takes precedence over detected QRGs and band designators in the name field. The affected band is no longer offered as `a` or `B+`, is not counted as an opportunity by the **New bands** filter and is excluded by the corresponding band filter.
In plain terms: an automatically detected hint means "probably active on this band". A manual NOT-QRV mark means "do not request this station on this band". The next detected number must not silently reverse that decision.
### Storage and lifetime
Worked, NOT-QRV and worked-grid information is stored in the internal SQLite database and restored on the next start. Entries expire automatically after three days, so a reset before every contest is normally unnecessary.
A manual reset under **Workedstn database** removes all Worked marks, NOT-QRV marks and stored worked grid squares. The known callsign rows remain in the database. See [Worked Station Database Settings](en-Configuration#worked-station-database-settings) for details.
## Direction Filter
@@ -83,9 +149,19 @@ Hide stations beyond a maximum distance. The **"Show only QRB [km] <="** button
---
## Worked and NOT-QRV Filter
## Filters for Worked Status, New Bands and New Grid Squares
Toggle buttons (one per band) to hide already-worked stations and/or NOT-QRV-tagged stations. The filter takes effect **immediately** without manually reactivating (live since v1.22).
The filters above the user list use the same information as the Worked columns:
- **wkd** hides callsigns which have been worked on at least one band.
- The individual band buttons hide a station if the callsign has already been worked on that band or has manually been marked NOT QRV there.
- **New bands** shows only stations for which at least one locally enabled and unworked band is known. It evaluates recent QRG detections and band designators in the name field; NOT-QRV takes precedence.
- **Only new grids** shows only stations whose four-character grid square has not been worked on any band. Stations without a valid locator do not pass this filter.
- **Grid color** does not filter the list. When enabled, it gives the QRA cell of an already worked grid square a slightly darker background. New grid squares retain the normal table colour.
Several active filters are applied together. A station remains visible only if it satisfies every selected condition. The filters react immediately to new log entries and changed NOT-QRV marks.
Operation and layout of the filter bar: [User Interface Filters](en-User-Interface#filters).
---
@@ -135,19 +211,86 @@ For selected stations in the user list, there are direct buttons to open the **Q
---
## Sked Reminders with ALERT (from v1.40)
## Skeds and Sked Reminders
A sked reminder service with automatic messages can be activated for each chat member. Configurable interval patterns:
> Available from v1.40; band, callsign and Win-Test handling extended in Nightly / v1.42.
- **2+1 minutes**: Messages at 2 min and 1 min before the sked.
- **5+2+1 minutes**: Messages at 5, 2 and 1 min before the sked.
- **10+5+2+1 minutes**: Messages at 10, 5, 2 and 1 min before the sked.
A sked is more than a reminder tied to a particular time. During a contest, it must become visible early enough, move the agreed station up the priority list and if required remind the remote station as well.
In addition to the automated messages to the remote station, there is an **acoustic and visual notification** for your own operator so no sked is ever missed.
KST4Contest therefore treats three tasks separately:
Activate from the FurtherInfo panel of the corresponding station.
1. The sked is stored internally and included in the priority calculation.
2. The scheduled contact appears in the AP and sked timeline.
3. Automatic private reminder messages can optionally be sent before the agreed time.
When the Win-Test network listener is enabled, KST4Contest also attempts to hand the sked over to Win-Test. A failed handover neither removes nor prevents the internal sked.
### Creating a sked
First select the required station in the user list. The sked controls then appear at the bottom of the **Further Info** section.
| Control | Function |
|---|---|
| **Sked in** | Sets the number of minutes until the sked. Available values are 2 through 15 and 20 minutes. |
| **Band** | Selects the sked band. The dropdown contains the local bands enabled under **Station → my station uses …**. |
| **Mode** | Sets the mode passed to Win-Test. Available values are `SSB` and `CW`. This selection does not affect the internal sked or reminder PMs. |
| **Create sked** | Creates the internal sked and, if the Win-Test network listener is enabled, also attempts the Win-Test handover. |
| **Remind-PM in** | Enables automatic private reminder messages before the sked. |
| **2+1**, **5+2+1**, **10+5+2+1** | Selects how many minutes before the sked the reminder PMs are sent. |
![Sked controls in the Further Info section](sked_controls.png)
KST4Contest attempts to preselect a useful band. It checks the following information in this order:
1. a QRG of the selected station which is no more than 30 minutes old and belongs to a locally enabled band,
2. an unambiguous band designator in the station's name field, and
3. the first locally enabled band.
Active callsign variants belonging to the same base callsign are evaluated together when looking for recent band information. A manual NOT-QRV mark is taken into account by the automatic selection. The operator can still select another band explicitly when a different arrangement has been made.
### Effect on the Priority Score
A stored sked raises the score of the normalised base callsign:
| Time relative to the sked | Contribution to the score |
|---|---:|
| more than 15 minutes before the sked | `+40` |
| 15 to 3 minutes before the sked | continuous increase from `+300` towards `+1200` |
| less than 3 minutes before until 1 minute after the sked | `+5000` |
| more than 1 minute after the sked | no remaining sked boost |
The strong weighting immediately around the scheduled time is intentional. An agreed sked should not disappear from the priority list merely because another station is currently very active but has no fixed appointment.
The score is calculated for the base callsign. A sked created for `DN9APW-2` therefore also affects the shared score of other active `DN9APW` variants. The actual message target nevertheless remains `DN9APW-2` in the chat category selected when the sked was created.
The sked is removed from the internal list five minutes after its scheduled time.
### Reminder PMs
Reminder PMs are only scheduled when **Remind-PM in** is enabled. Depending on the selected pattern, KST4Contest sends a private message such as the following two and one minute before the sked:
```text
[KST4C Autoreminder] sked in 2 min
```
The message is sent to the complete visible KST callsign in the chat category in which the sked was created. A sked for `DN9APW-2` is therefore not accidentally sent to `DN9APW`, `DN9APW-70` or a similarly named station in another category.
When a reminder is actually triggered, KST4Contest also displays the visual **SKED** indication. If simple notification sounds are enabled, a short sound is played as well. Merely arming a reminder does not start the blinking indication.
Creating a new set of reminders for the same complete callsign replaces the previously scheduled reminders for that callsign.
### Storage and limitations
Skeds and reminder schedules are kept in memory only. Any skeds which are still required must be recreated after restarting KST4Contest.
The automatic band selection is derived from available chat information. It cannot prove that the station is still operating on the most recently mentioned QRG. Check the band, time and mode before pressing **Create sked**.
Operation: [Station Info Panel](en-User-Interface#station-info-panel-further-info)
Display: [AP and Sked Timeline](#ap-and-sked-timeline)
Win-Test handover: [Log Synchronisation Win-Test](en-Log-Sync#win-test)
---
## QSO Sniffer (from v1.31)
@@ -157,17 +300,22 @@ Configuration: [Configuration Sniffer Settings](en-Configuration#sniffer-set
---
## Win-Test Integration (from v1.31, fully configurable from v1.40)
## Win-Test Integration
KST4Contest fully supports [Win-Test](https://www.win-test.com/) as a logging programme:
KST4Contest uses a dedicated listener for the native Win-Test network protocol. It provides three separate functions:
- **Log synchronisation**: Worked stations are automatically retrieved from Win-Test and marked in the user list.
- **Frequency parsing**: The current TRX frequency is read from Win-Test UDP packets and populates the `MYQRG` variable.
- **Sked handover (SKED push via UDP)**: Agreed skeds from KST4Contest can be pushed directly to Win-Test, so the remote callsign appears in Win-Test's sked window.
- importing new QSOs including band and, where available, locator information,
- reading the current QRG from Win-Test STATUS packets, and
- handing internally created skeds over to the Win-Test network as `ADDSKED` packets.
Details: [Configuration Win-Test Network Listener](en-Configuration#win-test-network-listener)
The sked handover does not replace a missing QRG with a fixed default frequency. KST4Contest only sends a Win-Test sked when it can determine a QRG which belongs to the selected band. The internal sked, timeline and reminder PMs continue to work independently.
A visible KST suffix such as `-2`, `-70` or `-144` is retained inside KST4Contest but removed from the callsign passed to the Win-Test log. Portable components such as `/P`, `/M` and country prefixes are preserved.
Setup and data handling: [Log Synchronisation Win-Test](en-Log-Sync#win-test)
Settings: [Win-Test Network Listener](en-Configuration#win-test-network-listener-from-v131)
---
## PSTRotator Interface (from v1.31, fully configurable from v1.40)
@@ -177,46 +325,181 @@ Configuration: [Configuration PSTRotator Settings](en-Configuration#pstrotat
---
## Band Alert for New QSOs (from v1.40)
## Band Upgrade Hint after a Log Entry
When a station is logged, KST4Contest automatically checks whether that station has shown any other active bands in the chat that you are also QRV on. If so, a **hint alert** appears so no multi-band opportunity is missed.
When UCXLog or Win-Test reports a new log entry with band information, KST4Contest checks whether the worked station still offers another common band.
The calculation follows the same rules as `a`, `B+` and the **New bands** filter: locally enabled bands, recent QRG detections, band designators in the name field, per-band Worked marks and NOT-QRV marks. Active chat variants of the same normalised callsign are evaluated together.
If at least one common and unworked band remains, a blinking hint appears for approximately twelve seconds. It includes the callsign and the remaining bands, for example `BAND+ DL0ABC 432, 1296`. Its tooltip also lists the enabled, worked and NOT-QRV bands used for the decision. If general notification sounds are enabled, KST4Contest also plays a short sound.
The Simplelogfile interpreter cannot trigger this hint reliably because it provides no band information for the QSO which has just been logged.
Configuration: [Band Upgrade Hint after a Log Entry](en-Configuration#band-upgrade-hint-after-a-log-entry).
Worked, NOT-QRV and worked-grid data expire automatically after three days. See [Worked Station Database Settings](en-Configuration#worked-station-database-settings) for the lifetime and manual reset behaviour.
---
## Worked Tag Lifetime (from v1.40)
## Priority Score and Priority List (from v1.40)
Worked stations are automatically removed from the database after **3 days**. Manually resetting the worked database before each contest is therefore no longer strictly necessary the database keeps itself up to date.
### Why is a score needed at all?
A conventional chat user list initially tells the operator only which stations are logged in. That is not enough during a contest. The operator must also consider which stations have not yet been worked, which bands may still be available, where the antenna is pointing, whether a suitable aircraft is approaching and whether an agreed sked is about to begin.
With a short list, much of this can still be handled mentally. As the contest continues, several bands are used and two chat categories are monitored at the same time, the same decision has to be reconstructed over and over again.
KST4Contest therefore combines the available information into a priority score. The score does not answer whether a QSO will definitely be possible. It supports the more practical question:
> Which of the currently visible stations should I examine next?
### When is a station excluded?
Before applying the weighted factors, KST4Contest checks whether a known band opportunity exists. All active chat entries belonging to the same normalised base callsign are evaluated together.
The calculation uses:
1. the bands enabled in the local station settings,
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.
NOT QRV takes precedence over automatically detected frequencies and band designators.
If the remote stations bands are known but none of them is both enabled locally and still available, the station receives a score of `0`. The same applies when every common band opportunity has already been worked.
A station is not excluded merely because all band information is missing. An unknown band opportunity is not the same as a known incompatibility. In this case, the station is removed from consideration only if all locally enabled bands have been manually marked NOT QRV for that station.
Stations with a score of `0` remain visible in the user list but are not included in the priority list.
### Which information raises or lowers the score?
The score combines several independent hints. One factor will therefore not normally determine the final position on its own.
| Factor | Effect on priority |
|---|---|
| Worked status | A callsign which has not been worked on any supported band receives a higher initial priority. A station which has already been worked is ranked lower but remains a candidate when another band opportunity is available. |
| Available bands | Several common and unworked bands raise the priority. An additional boost for band-upgrade cases can be enabled separately. |
| Distance | Distances below 200 km are weighted lower. The range between 200 km and the configured maximum QRB is preferred. Stations beyond the maximum QRB are reduced substantially. If the QRB is unavailable, this factor is omitted. |
| Antenna direction | The score rises when the QTF to the station lies within half of the configured antenna beamwidth around the current local QTF. The closer both directions are, the stronger the effect. |
| AirScout | At least one currently reachable aircraft raises the score. An expected AP opportunity in zero, one or two minutes receives an additional time-dependent weighting. |
| Recent chat activity | A message received during the previous minute has a stronger effect than one received during the previous three minutes. Several incoming lines within the activity window raise the score further. |
| Positive signals | Detected terms such as `QRV`, `READY`, `RGR`, `OK`, `TNX` or comparable configured text patterns are treated as a positive hint for several minutes. |
| Reply behaviour | If another visible chat line from the station follows an outgoing `/cq` message quickly, the averaged reaction time raises the score. If no such line arrives before the configured timeout, a negative mark is added. |
| Skeds | A scheduled contact initially adds a small amount of priority. During the final 15 minutes, its influence increases continuously. From three minutes before until one minute after the scheduled time, the sked receives very high priority. |
| Failed attempt | **Sked fail** strongly reduces the stations score until the mark is removed with **Reset fail** or KST4Contest is restarted. |
The default activity window for counting incoming messages is 180 seconds. A message received during the previous 60 seconds is evaluated separately as current activity. The default no-reply timeout is 13 minutes.
For reply behaviour, KST4Contest cannot prove that a later public or private line is actually a reply to the operators request. Any subsequent line received from the same station therefore ends the pending response-time measurement. This is a practical approximation, not a statistically reliable response rate.
### What does a scheduled contact mean for the score?
A sked is a time-dependent operating commitment. An imminent sked must therefore take precedence over most normal activity and distance hints. Without this weighting, a station which happens to be very active in the chat could displace an agreed contact from the priority list.
The strongest sked boost is deliberately limited to the period from three minutes before until one minute after the scheduled time. A sked further in the future remains relevant but should not yet dominate current operation.
The score is calculated for the normalised base callsign. A sked entered for an active variant such as `9A0BB-23` therefore affects the common score of the chat entries belonging to `9A0BB`.
### How are multiple suffixes and chat categories handled?
Active callsigns such as `9A0BB-2`, `9A0BB-70`, `9A0BB-23` and `9A0BB-13` remain separate chat members. Messages can therefore still be addressed to the complete callsign in the correct chat category.
Worked, band, NOT-QRV and score information belongs to the common base callsign `9A0BB`. The score is calculated once and projected to all active variants. The user list may consequently contain several separate rows with the same score, while the priority list contains only one entry for the base station.
KST4Contest uses the most recently suitable active login in the last relevant chat category as the concrete message target. Selecting a priority candidate then resolves the complete callsign, including its suffix and chat category.
### Updating and displaying the score
New messages, AirScout data, skeds, Worked information and manual NOT-QRV or Sked-fail changes request a new calculation immediately. The score is also refreshed periodically because activity, AP and sked information changes with time even when no new event is received.
A delay of a few seconds between an event and the visible new order is therefore normal.
The user interface displays the score in three places:
- the numerically sortable **Score** column in the user list,
- the **Further Info** section for the selected station, and
- the compact list of the two highest-ranked candidates, with a separate window containing up to 15 candidates.
Operation: [Priority List in the User Interface](en-User-Interface#priority-list).
### What does the score not tell you?
The numerical value is neither a success probability nor a signal prediction. A score which is twice as high does not mean that the QSO is twice as likely.
Among other things, the calculation does not know:
- the actual antenna direction of the remote station,
- its current operating situation,
- local interference,
- short-term propagation changes,
- terrain obstruction outside the connected assessment functions, or
- whether a station which is active in the chat is currently sitting at the radio.
Known input data may also be outdated or ambiguous. A detected frequency, for example, proves only that the QRG recently appeared in connection with that station.
In practical terms, the score does not replace the operators decision. It prevents the information already available to KST4Contest from having to be reconstructed mentally for every candidate.
Related settings:
- [Enabled Bands](en-Configuration#enabled-bands)
- [Antenna Beamwidth](en-Configuration#antenna-beamwidth)
- [Default Maximum QRB](en-Configuration#default-maximum-qrb)
- [AirScout Settings](en-Configuration#airscout-settings)
- [Band Upgrade Hint and Priority Boost](en-Configuration#band-upgrade-hint-after-a-log-entry)
---
## Chatmember Score System / Priority List (from v1.40)
## AP and Sked Timeline
KST4Contest automatically calculates a **priority score** for each active chat member. The score is derived from:
The timeline combines upcoming aircraft-scatter opportunities and stored skeds for the next 30 minutes. It therefore answers two different questions in the same place:
- Antenna direction of the remote station (is it pointing towards me?)
- QRB (distance)
- Activity time and message count
- Active bands and frequencies
- AP availability (AirScout)
- Sked direction (degrees)
- Sked success rate and skedfail markings
- When is an interesting AP opportunity expected?
- Which previously agreed sked is approaching independently of that opportunity?
The top candidates are highlighted in a dedicated priority list, helping you not to miss the most important contacts during contest stress.
Events further in the future appear on the right. As time passes, they move left towards the current time.
Stations with a failed sked can be marked using the **Skedfail button** in the FurtherInfo panel this temporarily lowers their score.
![AP candidates and skeds in the timeline](sked_timeline.png)
---
### AP candidates
## AP Timeline (from v1.40)
AP candidates appear in the upper lanes. Up to four selected candidates can be displayed for each aircraft arrival minute. The selection takes the Priority Score and the reflection potential reported by AirScout into account.
A visual timeline shows up to 4 highly-scored stations per minute slot that should be workable via aircraft scatter. Prioritisation criteria:
The colour of an AP marker represents the reflection potential:
- **Highest reflection potential** is preferred (not necessarily the fastest arrival).
- Stations towards which your antenna is not pointing are shown **transparently**.
| Colour | Reflection potential |
|---|---:|
| Magenta | at least 95% |
| Red | at least 75% |
| Yellow | at least 50% |
| Blue | below 50% |
The colour is not a QSO probability. It represents the AirScout value for the calculated reflection geometry.
Clicking an AP candidate selects the corresponding active chat member, including its callsign suffix and chat category. A suitable message can then be prepared immediately.
### Skeds
Skeds appear as diamonds in the lower lane. Their labels use the complete KST callsign, for example `SKED: DN9APW-2`. This makes it clear which particular login was selected for the scheduled contact.
A sked tooltip shows at least:
- the complete KST callsign,
- the agreed band, and
- the QTF towards the remote station.
Where suitable AirScout data is available, the tooltip also includes current AP reachability and the next calculated AP opportunity.
### Antenna direction
When the QTF of an event is clearly outside the current antenna direction, its marker becomes more transparent. The label remains readable. A target close to the centre of the configured antenna beam is highlighted.
This visual effect changes neither the sked nor the Priority Score. It is simply a quick way of identifying candidates which fit the current antenna direction.
The timeline is a preview. AirScout data can change, and a stored sked guarantees neither a clear frequency nor an actual propagation path.
This gives the contest operator a quick overview of which stations will be reachable via which aircraft and at what time.
---
## Interval Beacon
+91 -33
View File
@@ -2,7 +2,7 @@
> 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-Log-Synchronisation)
KST4Contest automatically marks worked stations in the chat user list. Two basic methods are available:
KST4Contest imports worked stations from the logging application and derives the global Worked status, per-band Worked marks and where a locator is available worked grid squares. Three input paths are available: the file-based Simplelogfile interpreter, the general QSO UDP listener and the dedicated Win-Test network listener.
---
@@ -10,24 +10,25 @@ KST4Contest automatically marks worked stations in the chat user list. Two basic
## Method 1: Universal File Based Callsign Interpreter (Simplelogfile)
KST4Contest reads a log file and searches for callsign patterns using a regular expression. Binary log files are also supported unreadable binary content is simply ignored.
KST4Contest reads a log file and searches it for callsigns using a configurable regular expression. The file is read only and is never modified. Binary log files can also be used; content which cannot be interpreted as text is skipped.
**Advantage**: Works with almost any logging program that writes a file.
**Disadvantage**: No band information available stations are only marked as "worked", not on which band.
The advantage is broad compatibility: no dedicated network interface is required from the logging application.
Enter the path to the log file in the Preferences. The file is only read, never modified (read-only).
The limitation is equally clear. A callsign match alone provides neither a reliable band nor a locator. The Simplelogfile interpreter can therefore set only the global Worked status. It does not create a per-band `X`, a worked-grid record or a reliable basis for the band-upgrade hint after a log entry.
> **Tip**: The Simplelogfile function can also be used to mark stations that are definitely unreachable (e.g. personal notes). This will be replaced in a later version by a better tagging system.
Configure the log-file path and regular expression in the **Log sync** tab. Use one of the network interfaces where possible if band-specific information is required.
---
## Method 2: Network Listener (UDP Broadcast) Recommended
# Method 2: Network Listener for QSO UDP Packets Recommended
When saving a QSO, the logging software sends a UDP packet to the broadcast address of the home network. KST4Contest receives this packet and marks the station including **band information** in its internal SQLite database.
UCXLog, QARTest, N1MM+ and DXLog.net can transmit a UDP packet when a QSO is saved. KST4Contest receives these packets on port `12060` by default and imports the callsign together with any band and locator information they contain.
> **Important**: KST4Contest must be **running in parallel with the logging software**. QSOs logged while KST4Contest is not running will not be captured except with QARTest (which can send the complete log).
If a band is available, the callsign is marked as worked on that band. If the packet also contains a valid locator, KST4Contest stores its four-character grid square for that band. Missing information is not inferred from unrelated fields.
**Default UDP port**: 12060 (matches the default of most logging programs)
KST4Contest must be running when the packet is transmitted. Some logging applications can, however, resend an existing log: QARTest provides **Invia log completo**, while DXLog.net sends `contactreplace` packets when broadcasting the complete log. KST4Contest processes both mechanisms.
**Default port:** `12060`
---
@@ -81,34 +82,81 @@ For the built-in DX cluster server: configure N1MM+ as a DX cluster client (serv
- Enter the IP of the KST4Contest computer (green-highlighted fields)
- Port: 12060
When broadcasting the complete logbook, DXLog.net uses `contactreplace` instead of `contactinfo`. KST4Contest processes both packet types. Older QSOs can therefore be imported by starting a complete-log broadcast while KST4Contest is running.
### Win-Test
Win-Test is supported with a dedicated UDP network listener that understands the native Win-Test network protocol.
Win-Test is connected through a dedicated UDP listener for the native Win-Test network protocol. This listener is independent of the general QSO UDP listener on port `12060`.
**Advantages of Win-Test Integration:**
- Automatic QSO synchronization to mark worked stations.
- **Sked Handover (ADDSKED):** Using the "Create sked" button in the station info panel not only creates a sked in KST4Contest but also *sends it directly via UDP to the Win-Test network as an ADDSKED packet* automatically, as soon as the listener is active. No separate toggle is needed.
- You can choose between "AUTO", "SSB", or "CW" sked modes.
- **Automatic QRG resolution for SKEDs:** KST4Contest selects the sked frequency intelligently:
1. If the other station mentioned their QRG in a recent chat message, that frequency is used.
2. Otherwise, your own current QRG is used (from Win-Test STATUS or manual entry).
#### QSO and Worked synchronisation
**Settings in the "Log Synchronisation" tab:**
- Enable `Receive Win-Test network based UDP log messages`.
- `UDP-Port for Win-Test listener` (default: 9871).
- `KST station name in Win-Test network (src of SKED packets)`: Defines the station name KST4Contest uses in the WT network (e.g. "KST").
- `Win-Test network broadcast address`: Usually detected automatically; required to send sked packets to the network.
For a new QSO, KST4Contest imports:
**Settings in the "TRX Synchronisation" tab:**
- `Win-Test STATUS QRG Sync`: When enabled, KST4Contest takes the current transceiver frequency from the Win-Test STATUS packet and uses it as your own QRG (MYQRG).
- `Use pass frequency from Win-Test STATUS`: Instead of the main TRX frequency, the pass frequency contained in the STATUS packet is used as MYQRG (useful for multi-op setups that operate with a dedicated pass QRG).
- `Win-Test station name filter`: If a name is entered here (e.g. "STN1"), KST4Contest only processes packets from that specific Win-Test instance. Leave empty to accept all.
- the logged callsign,
- the native Win-Test band ID, and
- a valid locator where one is included in the packet.
Band IDs for 50 and 70 MHz are processed in the same way as the VHF, UHF and SHF bands. The callsign is marked as worked globally and on the detected band. If a locator is also available, its four-character grid square is stored for that band.
The information is written to the same internal database as Worked data received through the other QSO UDP interfaces and is restored after a restart.
#### Handing skeds over to Win-Test
Pressing **Create sked** first creates an internal KST4Contest sked. If the Win-Test network listener is enabled, KST4Contest then automatically attempts to send the sked to the Win-Test network as an `ADDSKED` packet.
The QRG is selected in the following order:
1. KST4Contest looks for the most recent QRG of the remote station on the explicitly selected band. The QRG must be no more than 30 minutes old. Active variants of the same base callsign are evaluated together.
2. If no such QRG is available, KST4Contest checks the local QRG of the chat category in which the sked was created. It is only used if it can be parsed and actually belongs to the selected band.
3. If neither source provides a matching QRG, no `ADDSKED` packet is sent.
A fixed replacement frequency such as `144.300` is deliberately not used. During a contest, a technically successful handover containing the wrong band or QRG is worse than a visibly omitted handover.
The internal sked remains intact in every case. This also applies when the broadcast address is invalid, the network fails or no Win-Test client can be reached.
#### Handling KST callsign suffixes
KST suffixes often identify a particular chat login or band. They are not necessarily part of the log callsign. KST4Contest therefore removes a suffix separated by `-` before handing the callsign over to Win-Test, while preserving portable and international callsign components:
| Callsign in the KST chat | Callsign passed to Win-Test |
|---|---|
| `DN9APW-2` | `DN9APW` |
| `9A0BB-70` | `9A0BB` |
| `EA5/G8MBI/P-70` | `EA5/G8MBI/P` |
| `DN9APW-2/P` | `DN9APW/P` |
The complete callsign remains available inside KST4Contest. The timeline, reminder PMs and chat category continue to refer to the login which was actually selected.
#### Mode, time and notes
The mode is selected explicitly as `SSB` or `CW` when the sked is created. It is not inferred automatically from the QRG because a limited list of assumed band segments cannot represent every supported VHF, UHF and SHF band reliably.
KST4Contest sends the actual scheduled time without adding an extra minute. Where available, the notes include the locator and QTF together with an indication that the sked was created through KST4Contest.
The handover consists of the Win-Test packets `LOCKSKED`, `ADDSKED` and `UNLOCKSKED`.
![Sked handed over from KST4Contest to Win-Test](wintest_sked_handover.png)
#### Settings
In the **Log sync** tab:
- `Receive Win-Test network based UDP log messages`
- `UDP-Port for Win-Test listener`, default `9871`
- `KST station name in Win-Test network (src of SKED packets)`
- `Win-Test network broadcast address`
In the **TRX sync** tab:
- `Win-Test STATUS QRG Sync`
- `Use pass frequency from Win-Test STATUS`
- `Win-Test station name filter`
The Win-Test network must be enabled in Win-Test. When several computers are used, the broadcast address must reach the relevant local network. The station name should identify the sending KST4Contest instance unambiguously within the Win-Test network.
Detailed settings: [Win-Test Network Listener](en-Configuration#win-test-network-listener-from-v131)
**Settings in Win-Test:**
- The network in Win-Test must be active.
- Win-Test must be configured to send/receive its broadcasts on the corresponding port (default 9871).
---
## TRX Frequency Synchronisation
@@ -144,6 +192,16 @@ For DM5M-style setups (2 radios, 2 computers, one KST4Contest instance or two se
## Internal Database
KST4Contest stores worked information in an internal **SQLite database**. This is independent of the logging program's database and is only populated via the UDP broadcast.
KST4Contest stores Worked, NOT-QRV and worked-grid information in its own SQLite database. This database is independent of the logging application's database.
Before each new contest: reset the database! → [Configuration Worked Station Database Settings](Configuration#worked-station-database-settings)
The input sources provide different levels of detail:
| Source | Global callsign status | Per-band status | Grid square |
|---|---:|---:|---:|
| Simplelogfile | yes | no | no |
| QSO UDP listener | yes | yes, if included in the packet | yes, if both band and locator are available |
| Win-Test network listener | yes | yes | yes, if a locator is available |
The information is restored when KST4Contest starts and updated during operation when new log entries arrive. It expires automatically after three days, so a reset before every contest is normally unnecessary.
A complete manual reset removes Worked marks, NOT-QRV marks and worked grid squares together. See [Worked Station Database Settings](en-Configuration#worked-station-database-settings) for details.
+96 -15
View File
@@ -26,14 +26,29 @@ The central table of all currently active chat users. Columns (depending on conf
| Column | Content |
|---|---|
| Call | Station's callsign |
| Name | Name from the chat name field |
| Loc | Maidenhead locator |
| Callsign | Station callsign |
| Name | Name and additional information from the chat name field |
| QRA | Maidenhead locator |
| QRB | Distance in km |
| QTF | Direction in degrees |
| QRG | Automatically detected frequency |
| AP | AirScout aircraft data (when active) |
| Band colours | Worked / NOT-QRV status per band |
| QRG | Most recent frequency detected in a chat message |
| Tropo | Result of the band-specific tropo or path assessment |
| Score | Current, numerically sortable priority score of the normalised base callsign |
| Act | Minutes since the most recent activity |
| AP | AirScout aircraft data, when enabled |
| worked | Per-band Worked, band-opportunity and grid-square status, plus `wkdany` |
| NOT QRV @ | Bands on which the station has manually been marked not QRV |
| Category | Chat category of this entry |
### Worked, band and grid-square status
The subcolumns under **worked** use compact codes because several enabled bands leave little room for full descriptions. `X` marks a callsign worked on that band. `a` and `B+` identify an offered band which has not yet been worked. An appended `o` means that the four-character grid square has already been worked on this band.
The **wkdany** subcolumn is band-independent: `x` means that the callsign has been worked, `o` means that the grid square has been worked on any band, and `xo` means both.
Each status cell has a tooltip containing the legend and the state derived for that station. For the complete calculation, including NOT-QRV precedence, see [Worked Callsigns, New Bands and New Grid Squares](en-Features#worked-callsigns-new-bands-and-new-grid-squares).
![Band-specific Worked status and worked grid squares](worked_band_status.png)
**Sorting**: Click column headers. QRB sorting is numerical (corrected in v1.22).
@@ -53,26 +68,91 @@ Input field for the current antenna direction. Used for the planned `MYQTF` vari
## Filters
The filter bar (from v1.21 as a flowpane for small screens):
The filter bar is located above the chat-member table and groups related controls:
- **Show only QTF**: Activate direction filter (N/NE/E/… buttons or degree input)
- **Show only QRB [km] <=**: Activate distance filter (toggle button)
- **Hide Worked [Band]**: Hide worked stations per band (one toggle per band)
- **Hide NOT-QRV [Band]**: Hide NOT-QRV-tagged stations per band
- **Show only QTF** limits the list to a selected antenna direction.
- **Show only QRB [km] <=** sets a maximum distance.
- **Find** searches for a callsign.
- **wkd** hides callsigns which have already been worked on at least one band.
- The individual band buttons hide a station if it has already been worked on that band or has been marked NOT QRV there. Only bands enabled for the local station are shown.
- **Only new grids** shows only stations in four-character grid squares which have not been worked on any band.
- **Grid color** is not a filter. It marks the QRA cell of an already worked grid square without hiding stations.
- **New bands** shows stations with at least one detected, locally enabled and unworked band opportunity. NOT-QRV marks take precedence.
- **Reachability**, **Tropo >=0dB** and **AS next 5m** limit the list according to the selected path or AirScout criteria.
The filter bar has no fixed width. QTF, Worked and Reachability controls initially use the available space in their respective rows. When the horizontal divider is moved to the right and the chat-member area becomes narrower, controls wrap only when their actual required width no longer fits.
![Wrapped filter bar in a narrow chat-member view](filter_bar_wrapped.png)
In plain terms: the filters determine the table contents, but no longer enforce the minimum width of the entire right-hand side. The bar remains compact in the normal layout and uses additional height only when the view becomes genuinely narrow. Moving the divider back to the left immediately returns the controls to the available rows.
---
## Station Info Panel (Further Info)
Bottom right: Shows all messages of a selected station (CQ messages and PMs in one panel). A message filter can be pre-configured via the default filter in the Preferences.
The lower-right panel combines the messages associated with the selected station. This includes public messages, private messages to the local station and, where visible in the chat, private messages addressed to other stations.
**Sked reminders** can also be activated here.
The selected filter controls which of these messages are displayed. Under **Settings → GUI**, the default filter can be set to:
- all messages,
- private messages to the local station,
- private messages to other stations, or
- public messages.
This setting changes the Further Info display only. Messages are neither discarded nor removed from the other message tables, and the filter can be changed at any time for the currently selected station.
The lower part of the panel contains per-band **Not QRV** marks for the selected station. Individual controls are shown for the bands enabled in the local station settings. **tag not qrv all** sets or removes the mark for every supported band, including bands which are not currently visible.
The change immediately affects the **NOT QRV @** column, band opportunities and the corresponding filters. It is stored in the internal database and restored after a restart.
![Per-band NOT-QRV marks in the Further Info panel](not_qrv_controls.png)
The current **Priority score** of the selected station is displayed in the same section.
**Sked fail** marks an unsuccessful attempt and strongly reduces the score of the normalised base callsign. **Reset fail** removes the mark. It applies to all active suffix and category variants of the station and remains active for the current program session.
The controls underneath are used to create a sked:
| Control | Meaning |
|---|---|
| **Sked in** | Time remaining until the sked |
| **Band** | Agreed band selected from the locally enabled bands |
| **Mode** | `SSB` or `CW` for a possible Win-Test handover |
| **Create sked** | Create the internal sked |
| **Remind-PM in** | Enable automatic reminder PMs |
| **2+1**, **5+2+1**, **10+5+2+1** | Times at which reminder PMs are sent before the sked |
![Sked controls in the Further Info section](sked_controls.png)
The proposed band is derived from recent QRG and name information for the station. It can be changed explicitly before creating the sked. The mode selection only affects the Win-Test handover; the internal sked and reminder PMs work independently.
**Create sked** always creates the appointment inside KST4Contest first. If the Win-Test network listener is active, KST4Contest then attempts an additional handover to Win-Test. If no QRG matching the selected band can be found or Win-Test cannot be reached, the internal sked, its priority contribution and any scheduled reminders remain intact.
The complete derivation and limitations are described under [Skeds and Sked Reminders](en-Features#skeds-and-sked-reminders).
---
## Priority List
Shows the top candidates calculated by the Score Service. Updates automatically in the background based on direction, distance and AP availability.
The compact priority bar is located on the right-hand side between the user list and the Further Info section. It displays the two currently highest-ranked candidates directly in the main window:
```text
Priority: 1 CALLSIGN SCORE 2 CALLSIGN SCORE more
```
Clicking either candidate selects the corresponding active chat member. The complete callsign, including its suffix and chat category, is used.
The **more** button opens a separate window containing up to 15 candidates. The list is sorted by descending score. Double-clicking an entry selects the candidate and closes the window.
![Priority Score, compact candidate list and Further Info controls](priority_score_overview.png)
Stations with a score of `0` are not included in the priority list. They remain visible in the user list so that the reason for their exclusion can be examined and, for example, an incorrect NOT-QRV mark can be changed.
The score is calculated for the normalised base callsign. Several active variants such as `9A0BB-2` and `9A0BB-70` may therefore display the same value in the user list. They nevertheless remain separate message targets.
New messages, AirScout data, skeds and status changes request a new calculation. A periodic refresh also runs in the background. A briefly outdated order is therefore not an error.
Calculation and limitations: [Priority Score and Priority List](en-Features#priority-score-and-priority-list-from-v140).
---
@@ -100,6 +180,7 @@ If you encounter display problems: delete the configuration file → KST4Contest
## Operating Tips
- **Keep the settings window open**: Quick access to enable/disable the beacon.
- **Right-click in the user list**: Opens the snippet menu and further actions (QRZ.com profile, set NOT-QRV tags).
- **Right-click in the user list**: Opens the snippet menu and other context actions.
- **Mark a station NOT QRV**: Select the station and use the per-band controls in the **Further Info** panel.
- **Enter from anywhere**: When text is in the send field, Enter sends directly even if the focus is elsewhere.
- **Stop the beacon**: Switch off the beacon while scanning frequencies to avoid flooding the chat with messages.
Binary file not shown.

After

Width:  |  Height:  |  Size: 324 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 389 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 119 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 61 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

+32 -11
View File
@@ -150,20 +150,32 @@
<version>${jetbrains.annotations.version}</version>
<scope>compile</scope>
</dependency>
<!--
<dependency>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>2.0.2</version>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>${junit.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>5.17.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>javax.xml.parsers</groupId>
<artifactId>jaxp-api</artifactId>
<version>1.4.5</version>
</dependency>
-->
<!--
<dependency>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>2.0.2</version>
</dependency>
<dependency>
<groupId>javax.xml.parsers</groupId>
<artifactId>jaxp-api</artifactId>
<version>1.4.5</version>
</dependency>
-->
</dependencies>
@@ -254,6 +266,15 @@
<version>${maven.surfire.plugin}</version>
<configuration>
<testFailureIgnore>true</testFailureIgnore>
<!--
Without this, Surefire's automatic module-path detection splits the
JUnit Platform jars across classpath and module-path inconsistently
(module org.junit.platform.commons ends up loaded while a class from
junit-platform-engine stays in the unnamed module), which fails with
an IllegalAccessError before any test can run. The project itself has
no module-info.java, so plain classpath execution is correct here.
-->
<useModulePath>false</useModulePath>
</configuration>
</plugin>
@@ -43,7 +43,7 @@ public class ApplicationConstants {
public static final String DISCONNECT_RDR_POISONPILL = "UNKNOWN: KST4C KILL POISONPILL_KILLTHREAD=: " + sessionRuntimeUniqueId; //whereever a (blocking) udp or tcp reader in an infinite loop gets this message, it will break this loop
public static final String AUTOANSWER_PREFIX = "[KST4C Automsg] "; // hard-coded marker (user can't remove it)
public static final String AUTOANSWER_PREFIX = "[KST4C Automsg]"; // hard-coded marker (user cannot remove it)
/**
* UI message retention limits.
@@ -1,122 +1,178 @@
package kst4contest.controller;
import java.util.Arrays;
import java.util.TimerTask;
import kst4contest.model.ChatMessage;
import kst4contest.model.ThreadStateMessage;
/**
* This class is for sending beacons intervalled to the public chat. Gets all
* preferences and instances via the Chatpreferences-object of the
* Chatcontroller.
* <br/><br/>
* The task will be runned out of the singleton ChatController instance in an
* intervall as specified by the Chatpreferences-instance (typically as
* configured in the xml file.
*
*
* @author prakt
* Sends the configured public-chat beacons for both active chat categories.
*
* <p>Both categories deliberately share one timer and therefore the same
* interval. Their enable flags and message templates remain independent. Every
* run reads the current preferences, resolves global message variables and
* sends only the categories which are currently enabled.</p>
*/
public class BeaconTask extends TimerTask {
private ChatController chatController;
private ThreadStatusCallback callBackToController;
private String ThreadNickName = "MyBeacon";
private static final String THREAD_NICKNAME = "MyBeacon";
public BeaconTask(ChatController client, ThreadStatusCallback callback) {
this.callBackToController = callback;
this.chatController = client;
private final ChatController chatController;
private final ThreadStatusCallback callbackToController;
/**
* Creates one execution of the shared beacon timer.
*
* @param chatController controller providing preferences and the TX queue
* @param callbackToController callback used by the thread-status display
*/
public BeaconTask(
ChatController chatController,
ThreadStatusCallback callbackToController
) {
this.chatController = chatController;
this.callbackToController = callbackToController;
}
@Override
public void run() {
Thread.currentThread().setName("BeaconTask");
reportStatus(THREAD_NICKNAME, true, "initialized", false);
ThreadStateMessage threadStateMessage = new ThreadStateMessage(this.ThreadNickName, true, "initialized", false);
callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
Thread.currentThread().setName("BeaconTask");
ChatMessage beaconMSG = new ChatMessage();
String replaceVariables = this.chatController.getChatPreferences().getBcn_beaconTextMainCat();
replaceVariables = replaceVariables.replaceAll("MYQRG", this.chatController.getChatPreferences().getMYQRGFirstCat().getValue());
replaceVariables = replaceVariables.replaceAll("MYCALL", this.chatController.getChatPreferences().getStn_loginCallSign());
replaceVariables = replaceVariables.replaceAll("MYLOCATOR", this.chatController.getChatPreferences().getStn_loginLocatorMainCat());
replaceVariables = replaceVariables.replaceAll("MYQTF", this.chatController.getChatPreferences().getActualQTF().getValue() + "");
replaceVariables = replaceVariables.replaceAll("SECONDQRG", this.chatController.getChatPreferences().getMYQRGSecondCat().getValue() + "");
beaconMSG.setMessageText(
"MSG|" + this.chatController.getChatPreferences().getLoginChatCategoryMain().getCategoryNumber() + "|0|" + replaceVariables + "|0|");
beaconMSG.setMessageDirectedToServer(true);
ChatMessage beaconMSG2 = new ChatMessage();
String replaceVariables2 = this.chatController.getChatPreferences().getBcn_beaconTextSecondCat();
replaceVariables2 = replaceVariables2.replaceAll("MYQRG", this.chatController.getChatPreferences().getMYQRGFirstCat().getValue());
replaceVariables2 = replaceVariables2.replaceAll("MYCALL", this.chatController.getChatPreferences().getStn_loginCallSign());
replaceVariables2 = replaceVariables2.replaceAll("MYLOCATOR", this.chatController.getChatPreferences().getStn_loginLocatorMainCat());
replaceVariables2 = replaceVariables2.replaceAll("MYQTF", this.chatController.getChatPreferences().getActualQTF().getValue() + "");
replaceVariables2 = replaceVariables2.replaceAll("SECONDQRG", this.chatController.getChatPreferences().getMYQRGSecondCat().getValue() + "");
beaconMSG2.setMessageText(
"MSG|" + this.chatController.getChatPreferences().getLoginChatCategorySecond().getCategoryNumber() + "|0|" + replaceVariables + "|0|");
beaconMSG2.setMessageDirectedToServer(true);
/**
* beacon 1st Chatcategory
*/
if (this.chatController.getChatPreferences().isBcn_beaconsEnabledMainCat() ) {
System.out.println(new Utils4KST().time_generateCurrentMMDDhhmmTimeString()
+ " [BeaconTask, Info]: Sending CQ: " + beaconMSG.getMessageText());
this.chatController.getMessageTXBus().add(beaconMSG);
threadStateMessage = new ThreadStateMessage(this.ThreadNickName + " 1", true, "on", false);
callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
} else {
threadStateMessage = new ThreadStateMessage(this.ThreadNickName + " 1", false, "off", false);
callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
}
/**
* beacon 2nd Chatcategory
*/
if (this.chatController.getChatPreferences().isLoginToSecondChatEnabled()) { //only send if 2nd cat enabled
if (this.chatController.getChatPreferences().isBcn_beaconsEnabledSecondCat()) {
beaconMSG2.setMessageText(
"MSG|" + this.chatController.getChatPreferences().getLoginChatCategorySecond().getCategoryNumber() + "|0|" + replaceVariables2 + "|0|");
beaconMSG2.setMessageDirectedToServer(true);
System.out.println(new Utils4KST().time_generateCurrentMMDDhhmmTimeString()
+ " [BeaconTask, Info]: Sending CQ 2nd Cat: " + beaconMSG2.getMessageText());
this.chatController.getMessageTXBus().add(beaconMSG2);
threadStateMessage = new ThreadStateMessage(this.ThreadNickName + " 2", true, "on", false);
callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
} else {
threadStateMessage = new ThreadStateMessage(this.ThreadNickName + " 2", false, "off", false);
callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
}
}
MessageVariableResolver variableResolver =
new MessageVariableResolver(chatController.getChatPreferences());
sendMainCategoryBeacon(variableResolver);
sendSecondCategoryBeacon(variableResolver);
}
}
/**
* Sends the main-category beacon if it is currently enabled.
*/
private void sendMainCategoryBeacon(MessageVariableResolver variableResolver) {
if (!chatController.getChatPreferences().isBcn_beaconsEnabledMainCat()) {
reportStatus(THREAD_NICKNAME + " 1", false, "off", false);
return;
}
String resolvedText = variableResolver.resolveGlobalVariables(
chatController.getChatPreferences().getBcn_beaconTextMainCat()
);
ChatMessage beaconMessage = buildBeaconMessage(
chatController.getChatPreferences()
.getLoginChatCategoryMain()
.getCategoryNumber(),
resolvedText,
"main category"
);
if (beaconMessage == null) {
reportStatus(THREAD_NICKNAME + " 1", false, "invalid text", true);
return;
}
System.out.println(
new Utils4KST().time_generateCurrentMMDDhhmmTimeString()
+ " [BeaconTask, Info]: Sending main-category CQ: "
+ beaconMessage.getMessageText()
);
chatController.getMessageTXBus().add(beaconMessage);
reportStatus(THREAD_NICKNAME + " 1", true, "on", false);
}
/**
* Sends the second-category beacon if the second login and its beacon are
* currently enabled.
*/
private void sendSecondCategoryBeacon(
MessageVariableResolver variableResolver
) {
if (!chatController.getChatPreferences().isLoginToSecondChatEnabled()
|| !chatController.getChatPreferences()
.isBcn_beaconsEnabledSecondCat()) {
reportStatus(THREAD_NICKNAME + " 2", false, "off", false);
return;
}
String resolvedText = variableResolver.resolveGlobalVariables(
chatController.getChatPreferences().getBcn_beaconTextSecondCat()
);
ChatMessage beaconMessage = buildBeaconMessage(
chatController.getChatPreferences()
.getLoginChatCategorySecond()
.getCategoryNumber(),
resolvedText,
"second category"
);
if (beaconMessage == null) {
reportStatus(THREAD_NICKNAME + " 2", false, "invalid text", true);
return;
}
System.out.println(
new Utils4KST().time_generateCurrentMMDDhhmmTimeString()
+ " [BeaconTask, Info]: Sending second-category CQ: "
+ beaconMessage.getMessageText()
);
chatController.getMessageTXBus().add(beaconMessage);
reportStatus(THREAD_NICKNAME + " 2", true, "on", false);
}
/**
* Builds the server-directed message after validating the resolved payload.
*
* <p>The resolved text is checked rather than only the configured template
* because inserted values can increase the final message length.</p>
*
* @param categoryNumber ON4KST category number
* @param resolvedText fully resolved beacon payload
* @param categoryDescription text used in diagnostic output
* @return prepared message, or {@code null} if the payload is invalid
*/
private ChatMessage buildBeaconMessage(
int categoryNumber,
String resolvedText,
String categoryDescription
) {
if (resolvedText == null
|| resolvedText.length() > ChatController.MAX_BEACON_TEXT_LENGTH) {
int actualLength = resolvedText == null ? 0 : resolvedText.length();
System.out.println(
"[BeaconTask, Warning]: Beacon for "
+ categoryDescription
+ " was not sent because the resolved text contains "
+ actualLength
+ " characters; maximum is "
+ ChatController.MAX_BEACON_TEXT_LENGTH
+ "."
);
return null;
}
ChatMessage beaconMessage = new ChatMessage();
beaconMessage.setMessageText(
"MSG|" + categoryNumber + "|0|" + resolvedText + "|0|"
);
beaconMessage.setMessageDirectedToServer(true);
return beaconMessage;
}
/**
* Forwards one state update to the existing thread-status display.
*/
private void reportStatus(
String threadName,
boolean running,
String information,
boolean criticalState
) {
ThreadStateMessage stateMessage = new ThreadStateMessage(
threadName,
running,
information,
criticalState
);
callbackToController.onThreadStatus(THREAD_NICKNAME, stateMessage);
}
}
@@ -20,6 +20,7 @@ import javafx.collections.transformation.SortedList;
import kst4contest.ApplicationConstants;
import kst4contest.controller.interfaces.PstRotatorEventListener;
import kst4contest.locatorUtils.DirectionUtils;
import kst4contest.logic.BandOpportunityResolver;
import kst4contest.logic.PriorityCalculator;
import kst4contest.model.*;
import kst4contest.test.MockKstServer;
@@ -59,6 +60,10 @@ public class ChatController implements ThreadStatusCallback, PstRotatorEventList
private static final boolean DEBUG_BAND_UPGRADE_HINT = true; //for new band hint
public static final int MIN_BEACON_INTERVAL_MINUTES = 1;
public static final int MAX_BEACON_TEXT_LENGTH = 120;
private static final long INITIAL_BEACON_DELAY_MILLIS = 10_000L;
private PstRotatorClient rotatorClient;
private Consumer<Double> viewRotorCallback;
@@ -212,18 +217,11 @@ public class ChatController implements ThreadStatusCallback, PstRotatorEventList
}
/**
* Called when an external logger (Win-Test or UCXLog interface) reports that a QSO was logged.
* Called when an external logger reports that a QSO was logged.
*
* Process goal:
* 1) Detect whether the logged station is *still active (QRV)* on at least one *other* band
* that is enabled for "my station" (stn_bandActive[Band]) AND not worked yet (worked144/432/...).
* 2) If yes: trigger an on-screen hint (blinking status button) and play the existing sked-notification sound.
* 3) Request a score recompute so the station can become visible again (optional boost is applied in PriorityCalculator).
*
* IMPORTANT:
* - We do NOT use ChatMember.worked (UI-only filter flag) for scoring decisions.
* - We only use per-band worked flags (worked144, worked432, ...).
* - "QRV on band" is derived from recent entries in ChatMember.knownActiveBands.
* <p>The common resolver combines recent QRG evidence and station-name bands
* across every active callsignRaw variant. A manual NOT-QRV tag overrides this
* automatic evidence before the hint and priority boost are evaluated.</p>
*/
public void onExternalLogEntryReceived(String callSignRaw) {
@@ -237,26 +235,20 @@ public class ChatController implements ThreadStatusCallback, PstRotatorEventList
System.out.println("[BandUpgradeHint] LOG received for call=" + callRaw);
}
// 1) Determine which bands I am active on (configured at startup via stn_bandActive* flags)
EnumSet<Band> myEnabledBands = getMyEnabledBandsFromPrefs(chatPreferences);
EnumSet<Band> myEnabledBands =
BandOpportunityResolver.getEnabledStationBands(chatPreferences);
if (myEnabledBands.isEmpty()) return;
// 2) Determine which bands the station was recently seen active on (from Smart Frequency Extraction history)
final long now = System.currentTimeMillis();
final long maxAgeMs = TimeUnit.MINUTES.toMillis(30); // keep consistent with "recent activity" semantics
EnumSet<Band> stationOfferedBands = collectStationOfferedBandsFromHistory(callRaw, now, maxAgeMs);
List<ChatMember> variants = findActiveChatMembersByRawCall(callRaw);
BandOpportunityResolver.Resolution bandResolution =
BandOpportunityResolver.resolve(variants, System.currentTimeMillis());
EnumSet<Band> stationOfferedBands = bandResolution.getOfferedBands();
if (stationOfferedBands.isEmpty()) return;
// 3) Keep only bands that I can actually work
stationOfferedBands.retainAll(myEnabledBands);
if (stationOfferedBands.isEmpty()) return;
// 4) Determine already worked bands (per-band flags only)
EnumSet<Band> workedBands = collectWorkedBands(callRaw);
// 5) Remaining bands = offered enabled - worked
EnumSet<Band> remainingBands = EnumSet.copyOf(stationOfferedBands);
remainingBands.removeAll(workedBands);
EnumSet<Band> workedBands = bandResolution.getWorkedBands();
EnumSet<Band> remainingBands =
bandResolution.getUnworkedEnabledBands(myEnabledBands);
if (remainingBands.isEmpty()) return;
if (DEBUG_BAND_UPGRADE_HINT) {
@@ -264,34 +256,35 @@ public class ChatController implements ThreadStatusCallback, PstRotatorEventList
+ " enabled=" + formatBandsHuman(myEnabledBands)
+ " offered=" + formatBandsHuman(stationOfferedBands)
+ " worked=" + (workedBands.isEmpty() ? "-" : formatBandsHuman(workedBands))
+ " NOT-QRV=" + formatBandsHuman(bandResolution.getNotQrvBands())
+ " remaining=" + formatBandsHuman(remainingBands));
}
// 6) Build UI text (button + tooltip)
String remainingHuman = formatBandsHuman(remainingBands);
String shortText = "BAND+ " + callRaw + " " + remainingHuman;
String tooltip = "Logged " + callRaw + ", but station is still QRV on additional band(s): "
String tooltip = "Logged " + callRaw
+ ", but the station still offers additional band(s): "
+ remainingHuman
+ "\n(Enabled: " + formatBandsHuman(myEnabledBands)
+ " | Worked: " + (workedBands.isEmpty() ? "-" : formatBandsHuman(workedBands)) + ")";
+ " | Worked: " + (workedBands.isEmpty() ? "-" : formatBandsHuman(workedBands))
+ " | NOT QRV: " + formatBandsHuman(bandResolution.getNotQrvBands()) + ")";
ThreadStateMessage msg = new ThreadStateMessage("BandUpgradeHint", true, tooltip, false);
msg.setRunningInformationTextDescription(shortText);
// 7) Trigger status update -> View will blink a dedicated indicator button
onThreadStatus("BandUpgradeHint", msg);
// 8) Sound (re-use existing sked notification sound) - respects global simple-sound flag
if (chatPreferences.isNotify_playSimpleSounds()) {
try {
getPlayAudioUtils().playNoiseLauncher('!'); // same as SkedReminderService
getPlayAudioUtils().playNoiseLauncher('!');
} catch (Exception e) {
System.out.println("[ChatController, warning]: failed to play band-upgrade hint sound: " + e.getMessage());
System.out.println(
"[ChatController, warning]: failed to play band-upgrade hint sound: "
+ e.getMessage()
);
}
}
// 9) Make sure score reacts quickly (boost is applied in PriorityCalculator if enabled)
if (getScoreService() != null) {
getScoreService().requestRecompute("BandUpgradeHint");
}
@@ -302,77 +295,6 @@ public class ChatController implements ThreadStatusCallback, PstRotatorEventList
return callRaw.trim().toUpperCase(Locale.ROOT);
}
/** Helper: create enabled-band set from preferences. */
private static EnumSet<Band> getMyEnabledBandsFromPrefs(ChatPreferences prefs) {
EnumSet<Band> s = EnumSet.noneOf(Band.class);
if (prefs.isStn_bandActive144()) s.add(Band.B_144);
if (prefs.isStn_bandActive432()) s.add(Band.B_432);
if (prefs.isStn_bandActive1240()) s.add(Band.B_1296);
if (prefs.isStn_bandActive2300()) s.add(Band.B_2320);
if (prefs.isStn_bandActive3400()) s.add(Band.B_3400);
if (prefs.isStn_bandActive5600()) s.add(Band.B_5760);
if (prefs.isStn_bandActive10G()) s.add(Band.B_10G);
return s;
}
/**
* Helper: union of all recently detected "QRV on band" entries across *all* ChatMember instances
* having the same callSignRaw (because a callsign may exist multiple times with different categories).
*/
private EnumSet<Band> collectStationOfferedBandsFromHistory(String callRaw, long nowMs, long maxAgeMs) {
EnumSet<Band> offered = EnumSet.noneOf(Band.class);
for (ChatMember cm : findActiveChatMembersByRawCall(callRaw)) {
if (cm == null || cm.getCallSignRaw() == null) continue;
Map<Band, ChatMember.ActiveFrequencyInfo> map = cm.getKnownActiveBands();
if (map == null || map.isEmpty()) continue;
for (Map.Entry<Band, ChatMember.ActiveFrequencyInfo> e : map.entrySet()) {
if (e.getKey() == null || e.getValue() == null) continue;
long age = nowMs - e.getValue().timestampEpoch;
if (age >= 0 && age <= maxAgeMs) {
offered.add(e.getKey());
}
if (DEBUG_BAND_UPGRADE_HINT) {
System.out.println("[BandUpgradeHint] history call=" + callRaw
+ " band=" + e.getKey()
+ " freq=" + e.getValue().frequency
+ " ageMs=" + age);
}
}
}
return offered;
}
/**
* Helper: union of per-band worked flags across all ChatMember instances for the same call.
* IMPORTANT: ChatMember.worked is UI-only and NOT used here.
*/
private EnumSet<Band> collectWorkedBands(String callRaw) {
EnumSet<Band> worked = EnumSet.noneOf(Band.class);
for (ChatMember cm : findActiveChatMembersByRawCall(callRaw)) {
if (cm == null || cm.getCallSignRaw() == null) continue;
if (cm.isWorked144()) worked.add(Band.B_144);
if (cm.isWorked432()) worked.add(Band.B_432);
if (cm.isWorked1240()) worked.add(Band.B_1296);
if (cm.isWorked2300()) worked.add(Band.B_2320);
if (cm.isWorked3400()) worked.add(Band.B_3400);
if (cm.isWorked5600()) worked.add(Band.B_5760);
if (cm.isWorked10G()) worked.add(Band.B_10G);
if (cm.isWorked24G()) worked.add(Band.B_24G);
}
return worked;
}
private static String formatBandsHuman(EnumSet<Band> bands) {
if (bands == null || bands.isEmpty()) return "-";
return bands.stream().map(ChatController::bandToHumanLabel).sorted().reduce((a, b) -> a + ", " + b).orElse("-");
@@ -381,6 +303,8 @@ public class ChatController implements ThreadStatusCallback, PstRotatorEventList
private static String bandToHumanLabel(Band b) {
if (b == null) return "?";
return switch (b) {
case B_50 -> "6m";
case B_70 -> "4m";
case B_144 -> "2m";
case B_432 -> "70cm";
case B_1296 -> "23cm";
@@ -394,7 +318,6 @@ public class ChatController implements ThreadStatusCallback, PstRotatorEventList
}
public void stopRotator() {
if (rotatorClient != null) {
rotatorClient.stop();
@@ -708,8 +631,7 @@ public class ChatController implements ThreadStatusCallback, PstRotatorEventList
// writeThread.interrupt();
// readThread.interrupt();
beaconTimer.purge();
beaconTimer.cancel();
stopBeaconTimer();
ASQueryTimer.purge();
ASQueryTimer.cancel();
socketCheckTimer.purge();
@@ -850,24 +772,6 @@ public class ChatController implements ThreadStatusCallback, PstRotatorEventList
private final Map<String, ChatCategory> lastInboundCategoryByCallSignRaw =
new java.util.concurrent.ConcurrentHashMap<>();
/** Tracks the last time WE sent a message containing a QRG to a specific callsign (UPPERCASE).
* Compared against knownActiveBands.timestampEpoch to decide whose QRG to use in a SKED. */
private final Map<String, Long> lastSentQRGToCallsign =
new java.util.concurrent.ConcurrentHashMap<>();
/** Call this whenever we send a PM to {@code receiverCallsign} that contains our QRG. */
public void recordOutboundQRG(String receiverCallsign) {
if (receiverCallsign == null) return;
lastSentQRGToCallsign.put(receiverCallsign.trim().toUpperCase(), System.currentTimeMillis());
System.out.println("[ChatController] Recorded outbound QRG to: " + receiverCallsign);
}
/** Returns epoch-ms of when we last sent our QRG to this callsign, or 0 if never. */
public long getLastSentQRGTimestamp(String callsign) {
if (callsign == null) return 0L;
return lastSentQRGToCallsign.getOrDefault(callsign.trim().toUpperCase(), 0L);
}
private final ScoreService scoreService = new ScoreService(this, new PriorityCalculator(), 15);
private ScheduledExecutorService scoreScheduler;
private final StationMetricsService stationMetricsService = new StationMetricsService();
@@ -891,158 +795,420 @@ public class ChatController implements ThreadStatusCallback, PstRotatorEventList
}
/**
* Pushes a sked to Win-Test via UDP broadcast (LOCKSKED / ADDSKED / UNLOCKSKED).
* Runs on a background thread to avoid blocking the UI.
* Pushes a sked to Win-Test via UDP broadcast.
*
* <p>The internal sked is independent from this handover. If no frequency can
* be resolved safely for the selected band, the internal sked remains active,
* but no misleading Win-Test entry is created.</p>
*/
private void pushSkedToWinTest(ContestSked sked) {
new Thread(() -> {
try {
InetAddress broadcastAddr = InetAddress.getByName(
chatPreferences.getLogsynch_wintestNetworkBroadcastAddress());
int port = chatPreferences.getLogsynch_wintestNetworkPort();
String stationName = chatPreferences.getLogsynch_wintestNetworkStationNameOfKST();
Double frequencyKHz = resolveSkedFrequencyKHz(sked);
WinTestSkedSender sender = new WinTestSkedSender(stationName, broadcastAddr, port, this);
// Frequency resolution:
// Compare WHO sent a QRG most recently in the PM conversation:
// - OM sent their QRG last use OM's Last Known QRG (ChatMember.frequency)
// - WE sent our QRG last use our own Win-Test QRG (MYQRG)
// Fallback chain if no timestamps exist: OM's Last Known QRG hardcoded default
double freqKHz = -1.0;
final long SKED_FREQ_MAX_AGE_MS = 60 * 60 * 1000L; // 60 minutes
ChatMember targetMember = resolveSkedTargetMember(sked.getTargetCallsign());
// Collect timestamps: when did the OM last mention their QRG? When did WE last send ours?
long omLastQRGTimestamp = 0L;
double omLastQRGMhz = 0.0;
if (targetMember != null && sked.getBand() != null) {
ChatMember.ActiveFrequencyInfo fi = targetMember.getKnownActiveBands().get(sked.getBand());
if (fi != null && fi.frequency > 0
&& (System.currentTimeMillis() - fi.timestampEpoch) <= SKED_FREQ_MAX_AGE_MS) {
omLastQRGTimestamp = fi.timestampEpoch;
omLastQRGMhz = fi.frequency;
}
}
long ourLastQRGTimestamp = getLastSentQRGTimestamp(sked.getTargetCallsign());
// Decision: who was more recent?
if (omLastQRGTimestamp > 0 && omLastQRGTimestamp >= ourLastQRGTimestamp) {
// OM mentioned their QRG MORE RECENTLY (or at same time) use their QRG
freqKHz = omLastQRGMhz * 1000.0;
System.out.println("[ChatController] SKED freq: OM sent last → "
+ omLastQRGMhz + " MHz → " + freqKHz + " kHz");
} else if (ourLastQRGTimestamp > 0) {
// WE sent our QRG more recently use our Win-Test QRG
try {
String qrgStr = chatPreferences.getMYQRGFirstCat().get();
if (qrgStr != null && !qrgStr.isBlank()) {
String cleaned = qrgStr.trim().replace(".", "");
double parsed = Double.parseDouble(cleaned) / 100.0;
if (parsed > 50000) {
freqKHz = parsed;
System.out.println("[ChatController] SKED freq: WE sent last → "
+ freqKHz + " kHz (raw: " + qrgStr + ")");
}
}
} catch (NumberFormatException ignored) { }
if (frequencyKHz == null) {
reportSkippedWinTestSked(
sked,
"no recent or configured QRG matches "
+ sked.getBand().getDisplayLabel()
);
return;
}
// Fallback A: OM's Last Known QRG from KST field (if no PM QRG exchange found at all)
if (freqKHz < 0 && targetMember != null) {
try {
String memberQrg = targetMember.getFrequency().get();
if (memberQrg != null && !memberQrg.isBlank()) {
double mhz = Double.parseDouble(memberQrg.trim());
freqKHz = mhz * 1000.0;
System.out.println("[ChatController] SKED freq: fallback Last Known QRG → "
+ mhz + " MHz → " + freqKHz + " kHz");
}
} catch (NumberFormatException ignored) { }
String winTestCallsign =
toWinTestSkedCallsign(
sked.getTargetChatCallsign()
);
if (winTestCallsign == null || winTestCallsign.isBlank()) {
reportSkippedWinTestSked(
sked,
"the target callsign could not be converted"
);
return;
}
// Fallback B: hardcoded default
if (freqKHz < 0) {
freqKHz = 144300.0;
}
InetAddress broadcastAddress = InetAddress.getByName(
chatPreferences
.getLogsynch_wintestNetworkBroadcastAddress()
);
int port =
chatPreferences.getLogsynch_wintestNetworkPort();
String stationName =
chatPreferences
.getLogsynch_wintestNetworkStationNameOfKST();
WinTestSkedSender sender = new WinTestSkedSender(
stationName,
broadcastAddress,
port,
this
);
String targetLocator =
resolveSkedTargetLocator(
sked.getTargetCallsign()
);
// Build notes string with target locator/azimuth info like reference: [JO02OB - 279°]
String targetLocator = resolveSkedTargetLocator(sked.getTargetCallsign());
String notes = "sked via KST4Contest";
if (targetLocator != null && !targetLocator.isBlank() && sked.getTargetAzimuth() > 0) {
notes = String.format("[%s - %.0f°] %s", targetLocator, sked.getTargetAzimuth(), notes);
} else if (targetLocator != null && !targetLocator.isBlank()) {
notes = String.format("[%s] %s", targetLocator, notes);
if (targetLocator != null
&& !targetLocator.isBlank()
&& sked.getTargetAzimuth() > 0) {
notes = String.format(
"[%s - %.0f°] %s",
targetLocator,
sked.getTargetAzimuth(),
notes
);
} else if (targetLocator != null
&& !targetLocator.isBlank()) {
notes = String.format(
"[%s] %s",
targetLocator,
notes
);
} else if (sked.getTargetAzimuth() > 0) {
notes = String.format("[%.0f°] %s", sked.getTargetAzimuth(), notes);
notes = String.format(
"[%.0f°] %s",
sked.getTargetAzimuth(),
notes
);
}
// Determine mode: -1 = auto-detect, 0 = CW, 1 = SSB
String modeStr = chatPreferences.getLogsynch_wintestSkedMode();
int modeOverride = -1; // AUTO
if ("CW".equalsIgnoreCase(modeStr)) modeOverride = 0;
else if ("SSB".equalsIgnoreCase(modeStr)) modeOverride = 1;
String configuredMode =
chatPreferences.getLogsynch_wintestSkedMode();
sender.pushSkedToWinTest(sked, freqKHz, notes, modeOverride);
} catch (Exception e) {
System.out.println("[ChatController] Error pushing sked to Win-Test: " + e.getMessage());
e.printStackTrace();
/*
* Win-Test mode IDs:
* 0 = CW
* 1 = SSB
*
* SSB is the safe fallback for missing or obsolete settings.
* The former AUTO mode was frequency-based and could not produce
* reliable results on every supported VHF, UHF and SHF band.
*/
int winTestMode =
"CW".equalsIgnoreCase(configuredMode)
? 0
: 1;
sender.pushSkedToWinTest(
sked,
winTestCallsign,
frequencyKHz,
notes,
winTestMode
);
} catch (Exception exception) {
String message =
"Error pushing sked to Win-Test: "
+ exception.getMessage();
System.out.println(
"[ChatController] " + message
);
onThreadStatus(
"WT-SkedSend",
new ThreadStateMessage(
"WT-SkedSend",
false,
message,
true
)
);
exception.printStackTrace();
}
}, "WinTestSkedPush").start();
}
private ChatMember resolveSkedTargetMember(String targetCallsignRaw) {
if (targetCallsignRaw == null || targetCallsignRaw.isBlank()) {
/**
* Resolves the frequency used for the Win-Test sked.
*
* <ol>
* <li>Newest QRG detected for the target station on the selected band</li>
* <li>Own QRG belonging to the target's chat category</li>
* <li>No result: do not send the Win-Test sked</li>
* </ol>
*/
private Double resolveSkedFrequencyKHz(ContestSked sked) {
if (sked == null || sked.getBand() == null) {
return null;
}
List<ChatMember> matchingMembers = findActiveChatMembersByRawCall(targetCallsignRaw);
return matchingMembers.isEmpty() ? null : matchingMembers.get(0);
}
Double targetFrequencyKHz =
resolveRecentTargetFrequencyKHz(sked);
private String resolveSkedTargetLocator(String targetCallsignRaw) {
if (targetCallsignRaw == null || targetCallsignRaw.isBlank()) {
return null;
if (targetFrequencyKHz != null) {
System.out.println(
"[ChatController] SKED frequency from target: "
+ targetFrequencyKHz
+ " kHz on "
+ sked.getBand()
);
return targetFrequencyKHz;
}
for (ChatMember member : findActiveChatMembersByRawCall(targetCallsignRaw)) {
String locator = member.getQra();
if (locator != null && !locator.isBlank()) {
return locator.trim().toUpperCase(Locale.ROOT);
}
String ownQrg =
resolveOwnQrgForSkedCategory(
sked.getTargetChatCategory()
);
Double ownFrequencyKHz =
parseSkedFrequencyKHz(
ownQrg,
sked.getBand()
);
if (ownFrequencyKHz != null) {
System.out.println(
"[ChatController] SKED frequency from own category QRG: "
+ ownFrequencyKHz
+ " kHz on "
+ sked.getBand()
);
return ownFrequencyKHz;
}
return null;
}
// private ChatMember resolveSkedTargetMember(String targetCallsignRaw) {
// if (targetCallsignRaw == null || targetCallsignRaw.isBlank()) {
// return null;
// }
//
// List<ChatMember> matchingMembers = findActiveChatMembersByRawCall(targetCallsignRaw);
// return matchingMembers.isEmpty() ? null : matchingMembers.get(0);
//
// }
//
// private String resolveSkedTargetLocator(String targetCallsignRaw) {
// if (targetCallsignRaw == null || targetCallsignRaw.isBlank()) {
// return null;
// }
//
// String normalizedTargetCall = normalizeCallRaw(targetCallsignRaw);
//
// for (ChatMember member : findActiveChatMembersByRawCall(targetCallsignRaw)) {
// String locator = member.getQra();
// if (locator != null && !locator.isBlank()) {
// return locator.trim().toUpperCase(Locale.ROOT);
// }
// }
//
// return null;
// }
/**
* Returns the newest QRG detected on the selected band across all active
* suffix and category variants of the base callsign.
*/
private Double resolveRecentTargetFrequencyKHz(ContestSked sked) {
List<ChatMember> variants =
findActiveChatMembersByRawCall(
sked.getTargetCallsign()
);
long now = System.currentTimeMillis();
long newestTimestamp = Long.MIN_VALUE;
Double newestFrequencyKHz = null;
for (ChatMember member : variants) {
if (member == null || member.getKnownActiveBands() == null) {
continue;
}
ChatMember.ActiveFrequencyInfo frequencyInfo =
member.getKnownActiveBands().get(
sked.getBand()
);
if (frequencyInfo == null
|| frequencyInfo.frequency <= 0.0
|| !sked.getBand().isPlausible(
frequencyInfo.frequency
)) {
continue;
}
long ageMs = now - frequencyInfo.timestampEpoch;
if (ageMs < 0L
|| ageMs > BandOpportunityResolver
.RECENT_DYNAMIC_EVIDENCE_MAX_AGE_MS) {
continue;
}
if (frequencyInfo.timestampEpoch > newestTimestamp) {
newestTimestamp = frequencyInfo.timestampEpoch;
newestFrequencyKHz =
frequencyInfo.frequency * 1000.0;
}
}
return newestFrequencyKHz;
}
/**
* Returns the own QRG belonging to the chat category in which the target
* station was selected.
*/
private String resolveOwnQrgForSkedCategory(
ChatCategory targetCategory) {
if (sameChatCategory(
targetCategory,
getChatCategorySecondChat())) {
return chatPreferences
.getMYQRGSecondCat()
.get();
}
return chatPreferences
.getMYQRGFirstCat()
.get();
}
private boolean sameChatCategory(ChatCategory first,
ChatCategory second) {
return first != null
&& second != null
&& first.getCategoryNumber()
== second.getCategoryNumber();
}
/**
* Parses the QRG formats used by KST4Contest and Win-Test.
*
* <p>Examples: 144.300, 144.300.03, 144300 and 144300.0.</p>
*/
private Double parseSkedFrequencyKHz(String value,
Band expectedBand) {
if (value == null
|| value.isBlank()
|| expectedBand == null) {
return null;
}
String normalized = value
.trim()
.replace(',', '.')
.replaceAll("\\s+", "");
try {
java.util.regex.Matcher groupedFrequency =
java.util.regex.Pattern.compile(
"^(\\d{2,5})\\.(\\d{3})(?:\\.(\\d{1,2}))?$"
).matcher(normalized);
if (groupedFrequency.matches()) {
double frequencyKHz =
Integer.parseInt(groupedFrequency.group(1))
* 1000.0
+ Integer.parseInt(
groupedFrequency.group(2)
);
String subKHzPart =
groupedFrequency.group(3);
if (subKHzPart != null) {
double subKHz =
Integer.parseInt(subKHzPart);
frequencyKHz +=
subKHzPart.length() == 1
? subKHz / 10.0
: subKHz / 100.0;
}
return expectedBand.isPlausible(
frequencyKHz / 1000.0
) ? frequencyKHz : null;
}
double numericValue =
Double.parseDouble(normalized);
if (expectedBand.isPlausible(numericValue)) {
return numericValue * 1000.0;
}
if (expectedBand.isPlausible(
numericValue / 1000.0)) {
return numericValue;
}
} catch (NumberFormatException ignored) {
// Invalid or unsupported QRG format.
}
return null;
}
/**
* Removes KST dash suffixes while retaining ordinary amateur-radio slash
* notation such as /P, /M or a country prefix.
*
* <p>Examples:
* DN9APW-2 -> DN9APW
* EA5/G8MBI/P-70 -> EA5/G8MBI/P
* DN9APW-2/P -> DN9APW/P</p>
*/
private String toWinTestSkedCallsign(String chatCallsign) {
if (chatCallsign == null || chatCallsign.isBlank()) {
return null;
}
String normalized =
chatCallsign.trim().toUpperCase(Locale.ROOT);
return normalized.replaceAll(
"-[^/]*(?=/|$)",
""
);
}
private void reportSkippedWinTestSked(ContestSked sked,
String reason) {
String target =
sked == null
? "unknown station"
: sked.getTargetChatCallsign();
String message =
"Win-Test sked not sent for "
+ target
+ ": "
+ reason
+ ". The internal KST4Contest sked remains active.";
System.out.println(
"[ChatController] " + message
);
onThreadStatus(
"WT-SkedSend",
new ThreadStateMessage(
"WT-SkedSend",
false,
message,
true
)
);
}
private String resolveSkedTargetLocator(
String targetCallsignRaw) {
if (targetCallsignRaw == null
|| targetCallsignRaw.isBlank()) {
return null;
}
for (ChatMember member
: findActiveChatMembersByRawCall(
targetCallsignRaw)) {
String locator = member.getQra();
if (locator != null && !locator.isBlank()) {
return locator
.trim()
.toUpperCase(Locale.ROOT);
}
}
return null;
}
public StationMetricsService getStationMetricsService() {
return stationMetricsService;
@@ -1252,27 +1418,45 @@ private ObservableList<String>
}
/**
* Builds the active-member key. The raw/base callsign alone is not enough
* because the same station can be logged into multiple ON4KST categories at
* the same time. Therefore the category number is part of the key.
* Builds the unique identity key for one active ON4KST login.
*
* <p>The complete callsign must be preserved here. Callsigns such as
* {@code 9A0BB-2}, {@code 9A0BB-70} and {@code 9A0BB-144} represent different
* active chat sessions and must therefore remain separate objects, even when
* they are logged into the same chat category.</p>
*
* <p>The normalized base callsign ({@code callSignRaw}) is deliberately not
* used for this key. It remains the common station key for worked, band and
* NOT-QRV information.</p>
*/
private String buildActiveChatMemberKey(String callSign, ChatCategory category) {
String normalizedCallsign = ChatMember.normalizeCallSignToBaseCallSign(callSign);
if (normalizedCallsign == null || normalizedCallsign.isBlank()) {
if (callSign == null) {
return null;
}
int categoryNumber = category == null ? -1 : category.getCategoryNumber();
return normalizedCallsign.trim().toUpperCase(Locale.ROOT) + "|" + categoryNumber;
String fullCallSign = callSign.trim().toUpperCase(Locale.ROOT);
if (fullCallSign.isBlank()) {
return null;
}
int categoryNumber =
category == null ? -1 : category.getCategoryNumber();
return fullCallSign + "|" + categoryNumber;
}
private String buildActiveChatMemberKey(ChatMember member) {
if (member == null) {
return null;
}
String callSign = member.getCallSignRaw() != null ? member.getCallSignRaw() : member.getCallSign();
return buildActiveChatMemberKey(callSign, member.getChatCategory());
return buildActiveChatMemberKey(
member.getCallSign(),
member.getChatCategory()
);
}
/**
@@ -1370,6 +1554,51 @@ private ObservableList<String>
return matchingMembers;
}
/**
* Copies the band-specific NOT-QRV state to every active category variant of the
* same base callsign. The database already uses callSignRaw as its key; applying
* the state to the runtime model immediately prevents category-dependent B+,
* filter, map and score results before the next database refresh.
*
* @param sourceMember member whose current NOT-QRV checkboxes are authoritative
*/
public void propagateNotQrvStateToActiveMembers(ChatMember sourceMember) {
if (sourceMember == null) {
return;
}
String rawCall = sourceMember.getCallSignRaw() != null
? sourceMember.getCallSignRaw()
: sourceMember.getCallSign();
List<ChatMember> variants = findActiveChatMembersByRawCall(rawCall);
if (variants.isEmpty()) {
variants = List.of(sourceMember);
}
for (ChatMember target : variants) {
if (target == null) {
continue;
}
target.setQrv50(sourceMember.isQrv50());
target.setQrv70(sourceMember.isQrv70());
target.setQrv144(sourceMember.isQrv144());
target.setQrv432(sourceMember.isQrv432());
target.setQrv1240(sourceMember.isQrv1240());
target.setQrv2300(sourceMember.isQrv2300());
target.setQrv3400(sourceMember.isQrv3400());
target.setQrv5600(sourceMember.isQrv5600());
target.setQrv10G(sourceMember.isQrv10G());
}
if (scoreService != null) {
scoreService.requestRecompute("NOT-QRV state changed");
}
fireUserListUpdate("NOT-QRV state propagated to callsign variants");
}
/**
* Updates locator and derived direction values in the active model. The UI list
* contains the same member object, but the user-list refresh is still triggered
@@ -2239,6 +2468,78 @@ private ObservableList<String>
this.dbHandler = dbHandler;
}
/**
* Starts the shared beacon timer with the interval currently stored in the
* preferences.
*
* <p>Both chat categories deliberately use the same timer. The task checks the
* individual enable flag and text for each category every time it runs.</p>
*
* @param initialDelayMillis delay before the next beacon run
*/
private synchronized void scheduleBeaconTimer(long initialDelayMillis) {
stopBeaconTimer();
int configuredInterval =
chatPreferences.getBcn_beaconIntervalInMinutesMainCat();
int effectiveInterval =
Math.max(MIN_BEACON_INTERVAL_MINUTES, configuredInterval);
/*
* Keep both legacy XML values synchronized. The second value remains in the
* configuration for backward compatibility, but no longer represents an
* independent timer.
*/
chatPreferences.setBcn_beaconIntervalInMinutesMainCat(effectiveInterval);
chatPreferences.setBcn_beaconIntervalInMinutesSecondCat(effectiveInterval);
long intervalMillis = TimeUnit.MINUTES.toMillis(effectiveInterval);
long safeInitialDelay = Math.max(0L, initialDelayMillis);
beaconTimer = new Timer("BeaconTimer");
beaconTimer.schedule(
new BeaconTask(this, this),
safeInitialDelay,
intervalMillis
);
System.out.println("[ChatController, Info]: Shared beacon timer scheduled every "
+ effectiveInterval + " minute(s).");
}
/**
* Applies a changed beacon interval while the chat connection is running.
*
* <p>The countdown starts again with the new interval. No beacon is sent
* immediately merely because the setting was changed.</p>
*/
public synchronized void restartBeaconTimer() {
if (!isConnectedAndLoggedIn()) {
return;
}
long intervalMillis = TimeUnit.MINUTES.toMillis(
Math.max(
MIN_BEACON_INTERVAL_MINUTES,
chatPreferences.getBcn_beaconIntervalInMinutesMainCat()
)
);
scheduleBeaconTimer(intervalMillis);
}
/**
* Stops the shared beacon timer if it is currently running.
*/
private synchronized void stopBeaconTimer() {
if (beaconTimer == null) {
return;
}
beaconTimer.cancel();
beaconTimer.purge();
beaconTimer = null;
}
/**
* execute is the main entry point where the application starts.
* @throws InterruptedException
@@ -2338,11 +2639,7 @@ private ObservableList<String>
* The CQ-beacon-Task will be executed every time but checks for itself whether
* CQ messages are enabled or not
*/
// Timer beaconTimer;
beaconTimer = new Timer();
beaconTimer.schedule(new BeaconTask(this, this), 10000,
this.getChatPreferences().getBcn_beaconIntervalInMinutesMainCat() * 60000);
// 60000 * intervalInMinutes = IntervalInMillis
scheduleBeaconTimer(INITIAL_BEACON_DELAY_MILLIS);
/**
* The AS querier task will be executed every time but checks for itself whether
@@ -2890,6 +3187,8 @@ private ObservableList<String>
activeChatMember.setWorked3400(storedChatMemberState.isWorked3400());
activeChatMember.setWorked5600(storedChatMemberState.isWorked5600());
activeChatMember.setWorked10G(storedChatMemberState.isWorked10G());
activeChatMember.setWorked50(storedChatMemberState.isWorked50());
activeChatMember.setWorked70(storedChatMemberState.isWorked70());
activeChatMember.setQrv144(storedChatMemberState.isQrv144());
activeChatMember.setQrv432(storedChatMemberState.isQrv432());
activeChatMember.setQrv1240(storedChatMemberState.isQrv1240());
@@ -2897,6 +3196,8 @@ private ObservableList<String>
activeChatMember.setQrv3400(storedChatMemberState.isQrv3400());
activeChatMember.setQrv5600(storedChatMemberState.isQrv5600());
activeChatMember.setQrv10G(storedChatMemberState.isQrv10G());
activeChatMember.setQrv50(storedChatMemberState.isQrv50());
activeChatMember.setQrv70(storedChatMemberState.isQrv70());
}
}
@@ -36,8 +36,8 @@ public class DBController {
* Number of milliseconds after which worked/not-QRV data is considered outdated
* and therefore automatically reset.
*/
private static final long WORKED_DATA_EXPIRATION_IN_MILLISECONDS = 65L * 60L * 60L * 1000L;
private static final long WORKED_DATA_EXPIRATION_IN_MILLISECONDS =
3L * 24L * 60L * 60L * 1000L;
/**
* Database schema version that includes the raw-callsign normalization migration
* marker. The marker is stored in SQLite PRAGMA user_version so the expensive
@@ -145,6 +145,7 @@ public class DBController {
createWorkedGrossFieldTableIfRequired();
versionUpdateOfDBCheckAndChangeV11ToV12();
versionUpdateOfDBCheckAndChangeV12ToV13();
versionUpdateOfDBCheckAndChangeV13ToV14();
if (helper_isDatabaseSchemaVersionOlderThanCurrent() || helper_isCallsignNormalizationMigrationRequired()) {
normalizeStoredCallsignsToRawCallsigns();
@@ -230,6 +231,8 @@ public class DBController {
+ "worked3400 BOOLEAN DEFAULT 0, "
+ "worked5600 BOOLEAN DEFAULT 0, "
+ "worked10G BOOLEAN DEFAULT 0, "
+ "worked50 BOOLEAN DEFAULT 0, "
+ "worked70 BOOLEAN DEFAULT 0, "
+ "notQRV144 BOOLEAN DEFAULT 0, "
+ "notQRV432 BOOLEAN DEFAULT 0, "
+ "notQRV1240 BOOLEAN DEFAULT 0, "
@@ -237,6 +240,8 @@ public class DBController {
+ "notQRV3400 BOOLEAN DEFAULT 0, "
+ "notQRV5600 BOOLEAN DEFAULT 0, "
+ "notQRV10G BOOLEAN DEFAULT 0, "
+ "notQRV50 BOOLEAN DEFAULT 0, "
+ "notQRV70 BOOLEAN DEFAULT 0, "
+ "lastFlagsChangeEpochMs INTEGER DEFAULT 0"
+ ");";
@@ -303,6 +308,22 @@ public class DBController {
}
}
/**
* Updates old v1.3 databases to the v1.4 schema by adding the worked/not-QRV
* columns for the 50 MHz and 70 MHz bands if they are missing.
*/
public synchronized void versionUpdateOfDBCheckAndChangeV13ToV14() {
try {
ensureColumnExists("ChatMember", "worked50", "BOOLEAN DEFAULT 0");
ensureColumnExists("ChatMember", "worked70", "BOOLEAN DEFAULT 0");
ensureColumnExists("ChatMember", "notQRV50", "BOOLEAN DEFAULT 0");
ensureColumnExists("ChatMember", "notQRV70", "BOOLEAN DEFAULT 0");
} catch (SQLException e) {
throw new RuntimeException("[DBH, ERROR:] Could not migrate database from v1.3 to v1.4", e);
}
}
/**
* Adds a missing column to an existing table. This method is used for safe schema
* upgrades on customer systems which still contain older database files.
@@ -452,7 +473,11 @@ public class DBController {
targetChatMember.setWorked3400(targetChatMember.isWorked3400() || sourceChatMember.isWorked3400());
targetChatMember.setWorked5600(targetChatMember.isWorked5600() || sourceChatMember.isWorked5600());
targetChatMember.setWorked10G(targetChatMember.isWorked10G() || sourceChatMember.isWorked10G());
targetChatMember.setWorked50(targetChatMember.isWorked50() || sourceChatMember.isWorked50());
targetChatMember.setWorked70(targetChatMember.isWorked70() || sourceChatMember.isWorked70());
targetChatMember.setQrv50(targetChatMember.isQrv50() && sourceChatMember.isQrv50());
targetChatMember.setQrv70(targetChatMember.isQrv70() && sourceChatMember.isQrv70());
targetChatMember.setQrv144(targetChatMember.isQrv144() && sourceChatMember.isQrv144());
targetChatMember.setQrv432(targetChatMember.isQrv432() && sourceChatMember.isQrv432());
targetChatMember.setQrv1240(targetChatMember.isQrv1240() && sourceChatMember.isQrv1240());
@@ -491,6 +516,8 @@ public class DBController {
+ "worked3400 = 0, "
+ "worked5600 = 0, "
+ "worked10G = 0, "
+ "worked50 = 0, "
+ "worked70 = 0, "
+ "notQRV144 = 0, "
+ "notQRV432 = 0, "
+ "notQRV1240 = 0, "
@@ -498,6 +525,8 @@ public class DBController {
+ "notQRV3400 = 0, "
+ "notQRV5600 = 0, "
+ "notQRV10G = 0, "
+ "notQRV50 = 0, "
+ "notQRV70 = 0, "
+ "lastFlagsChangeEpochMs = 0 "
+ "WHERE lastFlagsChangeEpochMs > 0 AND lastFlagsChangeEpochMs < ?;";
@@ -534,9 +563,9 @@ public class DBController {
String insertOrUpdateSql =
"INSERT INTO ChatMember ("
+ "callsign, qra, name, lastActivityDateTime, worked, worked144, worked432, worked1240, worked2300, worked3400, worked5600, worked10G, "
+ "notQRV144, notQRV432, notQRV1240, notQRV2300, notQRV3400, notQRV5600, notQRV10G, lastFlagsChangeEpochMs"
+ ") VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) "
+ "callsign, qra, name, lastActivityDateTime, worked, worked144, worked432, worked1240, worked2300, worked3400, worked5600, worked10G, worked50, worked70, "
+ "notQRV144, notQRV432, notQRV1240, notQRV2300, notQRV3400, notQRV5600, notQRV10G, notQRV50, notQRV70, lastFlagsChangeEpochMs"
+ ") VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) "
+ "ON CONFLICT(callsign) DO UPDATE SET "
+ "qra = excluded.qra, "
+ "name = excluded.name, "
@@ -557,14 +586,18 @@ public class DBController {
preparedStatement.setInt(10, helper_booleanIntConverter(chatMemberToStore.isWorked3400()));
preparedStatement.setInt(11, helper_booleanIntConverter(chatMemberToStore.isWorked5600()));
preparedStatement.setInt(12, helper_booleanIntConverter(chatMemberToStore.isWorked10G()));
preparedStatement.setInt(13, helper_booleanIntConverter(!chatMemberToStore.isQrv144()));
preparedStatement.setInt(14, helper_booleanIntConverter(!chatMemberToStore.isQrv432()));
preparedStatement.setInt(15, helper_booleanIntConverter(!chatMemberToStore.isQrv1240()));
preparedStatement.setInt(16, helper_booleanIntConverter(!chatMemberToStore.isQrv2300()));
preparedStatement.setInt(17, helper_booleanIntConverter(!chatMemberToStore.isQrv3400()));
preparedStatement.setInt(18, helper_booleanIntConverter(!chatMemberToStore.isQrv5600()));
preparedStatement.setInt(19, helper_booleanIntConverter(!chatMemberToStore.isQrv10G()));
preparedStatement.setLong(20, resolvedLastFlagsChangeEpochMs);
preparedStatement.setInt(13, helper_booleanIntConverter(chatMemberToStore.isWorked50()));
preparedStatement.setInt(14, helper_booleanIntConverter(chatMemberToStore.isWorked70()));
preparedStatement.setInt(15, helper_booleanIntConverter(!chatMemberToStore.isQrv144()));
preparedStatement.setInt(16, helper_booleanIntConverter(!chatMemberToStore.isQrv432()));
preparedStatement.setInt(17, helper_booleanIntConverter(!chatMemberToStore.isQrv1240()));
preparedStatement.setInt(18, helper_booleanIntConverter(!chatMemberToStore.isQrv2300()));
preparedStatement.setInt(19, helper_booleanIntConverter(!chatMemberToStore.isQrv3400()));
preparedStatement.setInt(20, helper_booleanIntConverter(!chatMemberToStore.isQrv5600()));
preparedStatement.setInt(21, helper_booleanIntConverter(!chatMemberToStore.isQrv10G()));
preparedStatement.setInt(22, helper_booleanIntConverter(!chatMemberToStore.isQrv50()));
preparedStatement.setInt(23, helper_booleanIntConverter(!chatMemberToStore.isQrv70()));
preparedStatement.setLong(24, resolvedLastFlagsChangeEpochMs);
preparedStatement.executeUpdate();
} catch (SQLException e) {
System.err.println("[DBH, ERROR:] Chatmember could not been stored.");
@@ -646,8 +679,8 @@ public class DBController {
String resetAllWorkedDataSql =
"UPDATE ChatMember SET "
+ "worked = 0, worked144 = 0, worked432 = 0, worked1240 = 0, worked2300 = 0, worked3400 = 0, worked5600 = 0, worked10G = 0, "
+ "notQRV144 = 0, notQRV432 = 0, notQRV1240 = 0, notQRV2300 = 0, notQRV3400 = 0, notQRV5600 = 0, notQRV10G = 0, "
+ "worked = 0, worked144 = 0, worked432 = 0, worked1240 = 0, worked2300 = 0, worked3400 = 0, worked5600 = 0, worked10G = 0, worked50 = 0, worked70 = 0, "
+ "notQRV144 = 0, notQRV432 = 0, notQRV1240 = 0, notQRV2300 = 0, notQRV3400 = 0, notQRV5600 = 0, notQRV10G = 0, notQRV50 = 0, notQRV70 = 0, "
+ "lastFlagsChangeEpochMs = 0;";
try (Statement statement = connection.createStatement()) {
@@ -781,6 +814,8 @@ public class DBController {
+ "notQRV3400 = ?, "
+ "notQRV5600 = ?, "
+ "notQRV10G = ?, "
+ "notQRV50 = ?, "
+ "notQRV70 = ?, "
+ "lastFlagsChangeEpochMs = ? "
+ "WHERE callsign = ?;";
@@ -792,8 +827,10 @@ public class DBController {
preparedStatement.setInt(5, helper_booleanIntConverter(!chatMemberToStore.isQrv3400()));
preparedStatement.setInt(6, helper_booleanIntConverter(!chatMemberToStore.isQrv5600()));
preparedStatement.setInt(7, helper_booleanIntConverter(!chatMemberToStore.isQrv10G()));
preparedStatement.setLong(8, System.currentTimeMillis());
preparedStatement.setString(9, chatMemberToStore.getCallSignRaw());
preparedStatement.setInt(8, helper_booleanIntConverter(!chatMemberToStore.isQrv50()));
preparedStatement.setInt(9, helper_booleanIntConverter(!chatMemberToStore.isQrv70()));
preparedStatement.setLong(10, System.currentTimeMillis());
preparedStatement.setString(11, chatMemberToStore.getCallSignRaw());
int affectedRows = preparedStatement.executeUpdate();
@@ -821,9 +858,9 @@ public class DBController {
String upsertCompleteRowSql =
"INSERT INTO ChatMember ("
+ "callsign, qra, name, lastActivityDateTime, worked, worked144, worked432, worked1240, worked2300, worked3400, worked5600, worked10G, "
+ "notQRV144, notQRV432, notQRV1240, notQRV2300, notQRV3400, notQRV5600, notQRV10G, lastFlagsChangeEpochMs"
+ ") VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) "
+ "callsign, qra, name, lastActivityDateTime, worked, worked144, worked432, worked1240, worked2300, worked3400, worked5600, worked10G, worked50, worked70, "
+ "notQRV144, notQRV432, notQRV1240, notQRV2300, notQRV3400, notQRV5600, notQRV10G, notQRV50, notQRV70, lastFlagsChangeEpochMs"
+ ") VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) "
+ "ON CONFLICT(callsign) DO UPDATE SET "
+ "qra = excluded.qra, "
+ "name = excluded.name, "
@@ -836,6 +873,8 @@ public class DBController {
+ "worked3400 = excluded.worked3400, "
+ "worked5600 = excluded.worked5600, "
+ "worked10G = excluded.worked10G, "
+ "worked50 = excluded.worked50, "
+ "worked70 = excluded.worked70, "
+ "notQRV144 = excluded.notQRV144, "
+ "notQRV432 = excluded.notQRV432, "
+ "notQRV1240 = excluded.notQRV1240, "
@@ -843,6 +882,8 @@ public class DBController {
+ "notQRV3400 = excluded.notQRV3400, "
+ "notQRV5600 = excluded.notQRV5600, "
+ "notQRV10G = excluded.notQRV10G, "
+ "notQRV50 = excluded.notQRV50, "
+ "notQRV70 = excluded.notQRV70, "
+ "lastFlagsChangeEpochMs = excluded.lastFlagsChangeEpochMs;";
try (PreparedStatement preparedStatement = connection.prepareStatement(upsertCompleteRowSql)) {
@@ -858,14 +899,18 @@ public class DBController {
preparedStatement.setInt(10, helper_booleanIntConverter(chatMemberToStore.isWorked3400()));
preparedStatement.setInt(11, helper_booleanIntConverter(chatMemberToStore.isWorked5600()));
preparedStatement.setInt(12, helper_booleanIntConverter(chatMemberToStore.isWorked10G()));
preparedStatement.setInt(13, helper_booleanIntConverter(!chatMemberToStore.isQrv144()));
preparedStatement.setInt(14, helper_booleanIntConverter(!chatMemberToStore.isQrv432()));
preparedStatement.setInt(15, helper_booleanIntConverter(!chatMemberToStore.isQrv1240()));
preparedStatement.setInt(16, helper_booleanIntConverter(!chatMemberToStore.isQrv2300()));
preparedStatement.setInt(17, helper_booleanIntConverter(!chatMemberToStore.isQrv3400()));
preparedStatement.setInt(18, helper_booleanIntConverter(!chatMemberToStore.isQrv5600()));
preparedStatement.setInt(19, helper_booleanIntConverter(!chatMemberToStore.isQrv10G()));
preparedStatement.setLong(20, chatMemberToStore.getLastFlagsChangeEpochMs());
preparedStatement.setInt(13, helper_booleanIntConverter(chatMemberToStore.isWorked50()));
preparedStatement.setInt(14, helper_booleanIntConverter(chatMemberToStore.isWorked70()));
preparedStatement.setInt(15, helper_booleanIntConverter(!chatMemberToStore.isQrv144()));
preparedStatement.setInt(16, helper_booleanIntConverter(!chatMemberToStore.isQrv432()));
preparedStatement.setInt(17, helper_booleanIntConverter(!chatMemberToStore.isQrv1240()));
preparedStatement.setInt(18, helper_booleanIntConverter(!chatMemberToStore.isQrv2300()));
preparedStatement.setInt(19, helper_booleanIntConverter(!chatMemberToStore.isQrv3400()));
preparedStatement.setInt(20, helper_booleanIntConverter(!chatMemberToStore.isQrv5600()));
preparedStatement.setInt(21, helper_booleanIntConverter(!chatMemberToStore.isQrv10G()));
preparedStatement.setInt(22, helper_booleanIntConverter(!chatMemberToStore.isQrv50()));
preparedStatement.setInt(23, helper_booleanIntConverter(!chatMemberToStore.isQrv70()));
preparedStatement.setLong(24, chatMemberToStore.getLastFlagsChangeEpochMs());
preparedStatement.executeUpdate();
} catch (SQLException e) {
throw new RuntimeException("[DBH, ERROR:] Could not rebuild normalized ChatMember row", e);
@@ -894,6 +939,8 @@ public class DBController {
builtChatMember.setWorked3400(helper_IntToBooleanConverter(resultSet.getInt("worked3400")));
builtChatMember.setWorked5600(helper_IntToBooleanConverter(resultSet.getInt("worked5600")));
builtChatMember.setWorked10G(helper_IntToBooleanConverter(resultSet.getInt("worked10G")));
builtChatMember.setWorked50(helper_IntToBooleanConverter(resultSet.getInt("worked50")));
builtChatMember.setWorked70(helper_IntToBooleanConverter(resultSet.getInt("worked70")));
builtChatMember.setQrv144(!helper_IntToBooleanConverter(resultSet.getInt("notQRV144")));
builtChatMember.setQrv432(!helper_IntToBooleanConverter(resultSet.getInt("notQRV432")));
builtChatMember.setQrv1240(!helper_IntToBooleanConverter(resultSet.getInt("notQRV1240")));
@@ -901,6 +948,8 @@ public class DBController {
builtChatMember.setQrv3400(!helper_IntToBooleanConverter(resultSet.getInt("notQRV3400")));
builtChatMember.setQrv5600(!helper_IntToBooleanConverter(resultSet.getInt("notQRV5600")));
builtChatMember.setQrv10G(!helper_IntToBooleanConverter(resultSet.getInt("notQRV10G")));
builtChatMember.setQrv50(!helper_IntToBooleanConverter(resultSet.getInt("notQRV50")));
builtChatMember.setQrv70(!helper_IntToBooleanConverter(resultSet.getInt("notQRV70")));
builtChatMember.setLastFlagsChangeEpochMs(resultSet.getLong("lastFlagsChangeEpochMs"));
return builtChatMember;
@@ -922,6 +971,8 @@ public class DBController {
targetChatMember.setWorked3400(sourceChatMember.isWorked3400());
targetChatMember.setWorked5600(sourceChatMember.isWorked5600());
targetChatMember.setWorked10G(sourceChatMember.isWorked10G());
targetChatMember.setWorked50(sourceChatMember.isWorked50());
targetChatMember.setWorked70(sourceChatMember.isWorked70());
targetChatMember.setQrv144(sourceChatMember.isQrv144());
targetChatMember.setQrv432(sourceChatMember.isQrv432());
targetChatMember.setQrv1240(sourceChatMember.isQrv1240());
@@ -929,6 +980,8 @@ public class DBController {
targetChatMember.setQrv3400(sourceChatMember.isQrv3400());
targetChatMember.setQrv5600(sourceChatMember.isQrv5600());
targetChatMember.setQrv10G(sourceChatMember.isQrv10G());
targetChatMember.setQrv50(sourceChatMember.isQrv50());
targetChatMember.setQrv70(sourceChatMember.isQrv70());
targetChatMember.setLastFlagsChangeEpochMs(sourceChatMember.getLastFlagsChangeEpochMs());
}
@@ -954,6 +1007,10 @@ public class DBController {
return "worked5600";
} else if (chatMemberToStore.isWorked10G()) {
return "worked10G";
} else if (chatMemberToStore.isWorked50()) {
return "worked50";
} else if (chatMemberToStore.isWorked70()) {
return "worked70";
}
return null;
@@ -996,13 +1053,17 @@ public class DBController {
|| chatMemberToStore.isWorked3400()
|| chatMemberToStore.isWorked5600()
|| chatMemberToStore.isWorked10G()
|| chatMemberToStore.isWorked50()
|| chatMemberToStore.isWorked70()
|| !chatMemberToStore.isQrv144()
|| !chatMemberToStore.isQrv432()
|| !chatMemberToStore.isQrv1240()
|| !chatMemberToStore.isQrv2300()
|| !chatMemberToStore.isQrv3400()
|| !chatMemberToStore.isQrv5600()
|| !chatMemberToStore.isQrv10G();
|| !chatMemberToStore.isQrv10G()
|| !chatMemberToStore.isQrv50()
|| !chatMemberToStore.isQrv70();
}
/**
@@ -46,14 +46,56 @@ public class MessageBusManagementThread extends Thread {
private 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)?)";
private final String PTRN_QRG_CAT3 = "(([0-9]{3,5}[\\.|,| ]?[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)?)";
/*
* Frequency formats handled by the smart parser:
*
* Group 1: full frequencies, for example 144.210 or 10368.100
* Group 2: relative frequencies with a separator, for example .210 or ,210
* Group 3: bare three-digit values, for example 210
*
* Group 3 is deliberately subjected to an additional context check. Without
* that check, ordinary chat values such as 599 or a bare band name such as 144
* 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{3}(?:[.,]\\d{1,3})?)(?![\\d])"
+ "|(?<=\\s|^)(\\d{3})(?=\\s|$)"
);
// ==== Autoanswer Flood/Pingpong Protection ====
private static final String AUTOANSWER_PREFIX = ApplicationConstants.AUTOANSWER_PREFIX; // hard-coded marker (user can't remove it)
private static final long AUTOANSWER_COOLDOWN_MS = 45_000L; // 45_000L = 45s
/*
* A bare three-digit value is accepted only when the nearby text makes its
* meaning sufficiently clear. Examples:
*
* qrg 210
* QRG: 210
* freq is 210
* on 210
* pse 210
* at 210
* 210 MHz
* 210 qrg
*/
private static final Pattern BARE_FREQUENCY_PREFIX_CONTEXT_PATTERN =
Pattern.compile(
"(?i)\\b(?:qrg|freq(?:uency)?|on|pse|at)\\b"
+ "\\s*(?:is\\s*)?[:=@-]?\\s*$"
);
// Cooldown per opponent station (and ChatCategory) only setted if this client sends
private static final Pattern BARE_FREQUENCY_SUFFIX_CONTEXT_PATTERN =
Pattern.compile(
"(?i)^\\s*(?:mhz|qrg|freq(?:uency)?)\\b"
);
private static final int BARE_FREQUENCY_CONTEXT_CHARACTERS = 32;
// ==== Auto-answer flood/ping-pong protection ====
private static final String AUTOANSWER_PREFIX = ApplicationConstants.AUTOANSWER_PREFIX;
private static final long AUTOANSWER_COOLDOWN_MS = 120_000L; // two minutes
// Cooldown per remote station and chat category; updated only after this client sends.
private final Hashtable<String, Long> lastLocalAutoAnswerPerRemoteMs = new Hashtable<>();
// BufferedWriter bufwrtrDBGMSGOut;
// private String text;
@@ -201,145 +243,220 @@ public class MessageBusManagementThread extends Thread {
}
/**
* Smart Frequency Parser (V1.32)
* Replaces the old RegEx logic.
* Features:
* 1. Handles full frequencies (144.210) and short forms (.210, 210).
* 2. Handles extended precision/weird formatting (144.210.10, 144,210,10).
* 3. Prioritizes USER CONTEXT (History) over GLOBAL CONTEXT (Preferences).
* Detects complete and relative frequencies in a chat message and stores the
* result on the sender.
*
* <p>Complete frequencies determine their band directly. Relative frequencies
* first use the sender's most recent band context if that context is not older
* than 30 minutes. Only when no suitable sender context exists does the parser
* use the globally configured fallback band.</p>
*
* <p>A relative value beginning with a dot or comma is sufficiently explicit
* on its own. A bare three-digit value is ambiguous and is therefore accepted
* only with nearby frequency-related text.</p>
*
* @param message message whose text is inspected
* @param prefs preferences containing the global fallback band
*/
private void smartFrequencyExtraction(ChatMessage message, ChatPreferences prefs) {
// Regex Explanation:
// Part 1 (Full): Start (not digit), 3-5 digits, sep, 1-3 digits, OPTIONAL (sep, 1-3 digits)
// Matches: 144.210, 144.210.10, 10368.100
// Part 2 (Short1): Start (not digit), sep, 3 digits, OPTIONAL (sep, 1-3 digits)
// Matches: .210, .210.10, ,210
// Part 3 (Short2): Whitespace/Start, 3 digits, Whitespace/End
// Matches: " 210 ", " 144 "
String smartPattern = "(?<![\\d])(\\d{3,5}[.,]\\d{1,3}(?:[.,]\\d{1,3})?)(?![\\d])|(?<![\\d])([.,]\\d{3}(?:[.,]\\d{1,3})?)(?![\\d])|(?<=\\s|^)(\\d{3})(?=\\s|$)";
Pattern pattern = Pattern.compile(smartPattern);
Matcher matcher = pattern.matcher(message.getMessageText());
if (message == null || message.getMessageText() == null) {
return;
}
ChatMember sender = message.getSender();
// Safety check, in case sender is null (e.g., server message)
if (sender == null) return;
if (sender == null) {
return;
}
String messageText = message.getMessageText();
Matcher matcher = SMART_FREQUENCY_PATTERN.matcher(messageText);
while (matcher.find()) {
String foundRaw = matcher.group().trim();
boolean dottedShortForm = matcher.group(2) != null;
boolean bareShortForm = matcher.group(3) != null;
boolean shortForm = dottedShortForm || bareShortForm;
// --- PRE-PROCESSING: Normalize separators ---
// 1. Replace all commas with dots to unify format (144,210,10 -> 144.210.10)
foundRaw = foundRaw.replace(",", ".");
if (bareShortForm
&& !hasExplicitBareFrequencyContext(
messageText,
matcher.start(),
matcher.end()
)) {
continue;
}
String foundRaw = matcher.group().trim().replace(',', '.');
double finalDetectedFrequency = 0.0;
Band finalDetectedBand = null;
boolean isShortForm = false;
// --- STEP 1: Type Determination (Short or Full?) ---
if (shortForm) {
if (foundRaw.startsWith(".")) {
foundRaw = foundRaw.substring(1);
}
// Check if it starts with a dot (e.g. ".210") OR is just 3 digits ("210")
if (foundRaw.startsWith(".") || foundRaw.length() == 3) {
/*
* Priority 1: use this sender's most recently observed band if its
* information is not older than 30 minutes and the reconstructed
* frequency lies inside that band.
*/
long bestTimestamp = 0L;
// It is a short form.
// We strip the leading dot for calculation if present -> "210.10" or "210"
if (foundRaw.startsWith(".")) foundRaw = foundRaw.substring(1);
isShortForm = true;
} else {
// It is a full frequency (e.g., 144.210.10 or 144.210)
try {
// Normalize "144.210.10" to "144.21010" for Double.parseDouble
String normalizedFull = normalizeFrequencyString(foundRaw);
finalDetectedFrequency = Double.parseDouble(normalizedFull);
finalDetectedBand = Band.fromFrequency(finalDetectedFrequency);
} catch (NumberFormatException e) { continue; }
}
// --- STEP 2: Context Resolution (Only needed for Short Forms) ---
if (isShortForm) {
// A) HISTORY CHECK (Priority 1: What did THIS USER do recently?)
// We search for the most recent band where this short form makes physical sense.
long bestTimestamp = 0;
// Iterate over all bands where the user is known
// (Assumption: ChatMember has a getter getKnownActiveBands())
if (sender.getKnownActiveBands() != null) {
for (java.util.Map.Entry<Band, ChatMember.ActiveFrequencyInfo> entry : sender.getKnownActiveBands().entrySet()) {
for (java.util.Map.Entry<Band, ChatMember.ActiveFrequencyInfo> entry
: sender.getKnownActiveBands().entrySet()) {
Band candidateBand = entry.getKey();
ChatMember.ActiveFrequencyInfo info = entry.getValue();
// Timeout Check: Info must not be older than 30 mins (1,800,000 ms)
if (System.currentTimeMillis() - info.timestampEpoch > 1800000) continue;
if (candidateBand == null || info == null) {
continue;
}
// Try Reconstruction: Band Prefix + ShortForm
// Example: Band 144 (Prefix "144") + "." + "210.10" -> "144.210.10"
if (System.currentTimeMillis() - info.timestampEpoch > 1_800_000L) {
continue;
}
try {
String reconstructedStr = candidateBand.getPrefix() + "." + foundRaw;
String normalizedReconstruction = normalizeFrequencyString(reconstructedStr);
double attemptFreq = Double.parseDouble(normalizedReconstruction);
String reconstructed =
candidateBand.getPrefix() + "." + foundRaw;
double candidateFrequency = Double.parseDouble(
normalizeFrequencyString(reconstructed)
);
// Does this frequency fit into the candidate band?
if (candidateBand.isPlausible(attemptFreq)) {
// If we have multiple matches, pick the most recent one
if (info.timestampEpoch > bestTimestamp) {
finalDetectedFrequency = attemptFreq;
finalDetectedBand = candidateBand;
bestTimestamp = info.timestampEpoch;
}
if (candidateBand.isPlausible(candidateFrequency)
&& info.timestampEpoch > bestTimestamp) {
finalDetectedFrequency = candidateFrequency;
finalDetectedBand = candidateBand;
bestTimestamp = info.timestampEpoch;
}
} catch (Exception e) { /* Ignore parsing errors */ }
}
}
// B) GLOBAL PREFERENCES CHECK (Priority 2: Fallback if history is empty/old)
if (finalDetectedBand == null) {
// Get standard band from prefs (e.g., "144" or "432")
String defaultPrefix = prefs.getNotify_optionalFrequencyPrefix().get();
try {
String reconstructedStr = defaultPrefix + "." + foundRaw;
String normalizedReconstruction = normalizeFrequencyString(reconstructedStr);
double attemptFreq = Double.parseDouble(normalizedReconstruction);
// Check if this results in a valid amateur radio band
Band defaultBandCandidate = Band.fromFrequency(attemptFreq);
if (defaultBandCandidate != null) {
finalDetectedFrequency = attemptFreq;
finalDetectedBand = defaultBandCandidate;
} catch (NumberFormatException ignored) {
// Try the next known band.
}
} catch (NumberFormatException e) {
// Number was likely not a frequency (e.g., "73" or "599") and didn't fit any band
continue;
}
}
}
// --- STEP 3: Process Result ---
if (finalDetectedBand != null && finalDetectedFrequency > 0) {
/*
* Store the detected QRG in the thread-safe active-member model.
* The UI table is only a JavaFX mirror, so the MessageBus must not scan
* or mutate getLst_chatMemberList() here.
* Priority 2: use the configured fallback band. Invalid values from
* an older hand-edited configuration fall back safely to 144 MHz.
* The current UI itself offers only values from Band.values().
*/
client.applyDetectedFrequencyToActiveMembers(sender, finalDetectedBand, finalDetectedFrequency);
if (finalDetectedBand == null) {
String configuredPrefix = null;
System.out.println("[SmartParser] Detected for " + sender.getCallSign() + ": " +
finalDetectedFrequency + " MHz (" + finalDetectedBand + ") " +
(isShortForm ? "[derived from " + foundRaw + "]" : "[full match]"));
if (prefs != null
&& prefs.getNotify_optionalFrequencyPrefix() != null) {
configuredPrefix =
prefs.getNotify_optionalFrequencyPrefix().get();
}
// Optional: Trigger Cluster-Spot here if enabled
Band fallbackBand = Band.fromPrefix(configuredPrefix);
if (fallbackBand == null) {
fallbackBand = Band.B_144;
}
try {
String reconstructed =
fallbackBand.getPrefix() + "." + foundRaw;
double candidateFrequency = Double.parseDouble(
normalizeFrequencyString(reconstructed)
);
if (fallbackBand.isPlausible(candidateFrequency)) {
finalDetectedFrequency = candidateFrequency;
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.
}
}
if (finalDetectedBand == null || finalDetectedFrequency <= 0.0) {
continue;
}
/*
* Store the result in the thread-safe active-member model. The existing
* compatibility property used by the TableView and DX-Cluster code is
* updated by applyDetectedFrequencyToActiveMembers(...), too.
*/
client.applyDetectedFrequencyToActiveMembers(
sender,
finalDetectedBand,
finalDetectedFrequency
);
System.out.println(
"[SmartParser] Detected for "
+ sender.getCallSign()
+ ": "
+ finalDetectedFrequency
+ " MHz ("
+ finalDetectedBand
+ ") "
+ (shortForm
? "[derived from " + foundRaw + "]"
: "[full match]")
);
}
}
/**
* Checks whether a bare three-digit value is surrounded by text that identifies
* it as a frequency.
*
* <p>The check intentionally uses only a small area around the value. A remote
* occurrence of the word "QRG" elsewhere in a long message must not turn every
* three-digit number in that message into a frequency.</p>
*
* @param messageText complete chat message
* @param matchStart start index of the three-digit match
* @param matchEnd end index of the three-digit match
* @return {@code true} if the value has explicit frequency context
*/
static boolean hasExplicitBareFrequencyContext(
String messageText,
int matchStart,
int matchEnd
) {
if (messageText == null
|| matchStart < 0
|| matchEnd < matchStart
|| matchEnd > messageText.length()) {
return false;
}
int prefixStart = Math.max(
0,
matchStart - BARE_FREQUENCY_CONTEXT_CHARACTERS
);
int suffixEnd = Math.min(
messageText.length(),
matchEnd + BARE_FREQUENCY_CONTEXT_CHARACTERS
);
String prefixContext = messageText.substring(prefixStart, matchStart);
String suffixContext = messageText.substring(matchEnd, suffixEnd);
return BARE_FREQUENCY_PREFIX_CONTEXT_PATTERN
.matcher(prefixContext)
.find()
|| BARE_FREQUENCY_SUFFIX_CONTEXT_PATTERN
.matcher(suffixContext)
.find();
}
/**
* Helper: Normalizes weird frequency formats to valid Double strings.
* Example: "144.210.10" -> "144.21010"
@@ -485,76 +602,129 @@ public class MessageBusManagementThread extends Thread {
}
/**
* Resolves a message sender from the thread-safe active-member model. If a
* CH/CR message arrives before the matching user-enter message, a marked
* fallback sender is used. The returned sender is never null.
* Resolves a message sender from the thread-safe active-member model.
*
* <p>The local login is handled before the active-user lookup because the own
* ChatMember is intentionally not stored in the visible user list. This also
* prevents another active login with the same base callsign from replacing the
* identity of our own message echo.</p>
*/
private ChatMember resolveInboundSender(String senderCallSign, ChatCategory category, ChatMessage message) {
private ChatMember resolveInboundSender(
String senderCallSign,
ChatCategory category,
ChatMessage message
) {
String myCall =
this.client.getChatPreferences().getStn_loginCallSign();
if (senderCallSign != null
&& myCall != null
&& senderCallSign.equalsIgnoreCase(myCall)) {
ChatMember ownSender = new ChatMember();
ownSender.setCallSign(senderCallSign);
ownSender.setChatCategory(category);
ownSender.setAirPlaneReflectInfo(
new AirPlaneReflectionInfo()
);
return ownSender;
}
ChatMember lookup = new ChatMember();
lookup.setCallSign(senderCallSign);
lookup.setChatCategory(category);
ChatMember senderObj = this.client.findActiveChatMember(lookup);
ChatMember senderObj =
this.client.findActiveChatMember(lookup);
if (senderObj != null) {
senderObj.setActivityTimeLastInEpoch(new Utils4KST().time_generateCurrentEpochTime());
senderObj.setActivityTimeLastInEpoch(
new Utils4KST().time_generateCurrentEpochTime()
);
// Remember the last active category so later outgoing replies can be routed correctly.
this.client.rememberLastInboundCategory(senderObj.getCallSignRaw(), senderObj.getChatCategory());
this.client.rememberLastInboundCategory(
senderObj.getCallSignRaw(),
senderObj.getChatCategory()
);
// Metrics influence priority scoring; process them after message text is known.
this.client.getStationMetricsService().onInboundMessage(
senderObj.getCallSignRaw(),
System.currentTimeMillis(),
message == null ? null : message.getMessageText(),
this.client.getChatPreferences(),
this.client.getChatPreferences().getStn_loginCallSign()
myCall
);
this.client.getScoreService().requestRecompute(
"rx-chat-message"
);
this.client.getScoreService().requestRecompute("rx-chat-message");
return senderObj;
}
ChatMember fallbackSender = new ChatMember();
String myCall = this.client.getChatPreferences().getStn_loginCallSign();
if (senderCallSign != null && senderCallSign.equalsIgnoreCase(myCall)) {
fallbackSender.setCallSign(myCall);
} else {
fallbackSender.setCallSign("[n/a]" + senderCallSign);
}
fallbackSender.setCallSign("[n/a]" + senderCallSign);
fallbackSender.setChatCategory(category);
fallbackSender.setAirPlaneReflectInfo(new AirPlaneReflectionInfo());
fallbackSender.setAirPlaneReflectInfo(
new AirPlaneReflectionInfo()
);
return fallbackSender;
}
/**
* Resolves a message receiver from the active-member model. Unknown receivers
* are represented as explicit fallback objects instead of null. This keeps PM
* echo display and historic messages stable even if the target station already
* left the chat.
* Resolves a message receiver from the thread-safe active-member model.
*
* <p>The local login is handled before the active-user lookup. The receiver
* from the ON4KST packet therefore remains authoritative even if another
* station with the same base callsign is logged into the same category.</p>
*/
private ChatMember resolveInboundReceiver(String receiverCallSign, ChatCategory category) {
if (receiverCallSign == null || receiverCallSign.equals("0")) {
private ChatMember resolveInboundReceiver(
String receiverCallSign,
ChatCategory category
) {
if (receiverCallSign == null
|| receiverCallSign.equals("0")) {
return createAllReceiver();
}
String myCall =
this.client.getChatPreferences().getStn_loginCallSign();
if (myCall != null
&& receiverCallSign.equalsIgnoreCase(myCall)) {
ChatMember ownReceiver = new ChatMember();
ownReceiver.setCallSign(receiverCallSign);
ownReceiver.setChatCategory(category);
ownReceiver.setAirPlaneReflectInfo(
new AirPlaneReflectionInfo()
);
return ownReceiver;
}
ChatMember lookup = new ChatMember();
lookup.setCallSign(receiverCallSign);
lookup.setChatCategory(category);
ChatMember receiverObj = this.client.findActiveChatMember(lookup);
ChatMember receiverObj =
this.client.findActiveChatMember(lookup);
if (receiverObj != null) {
return receiverObj;
}
ChatMember fallbackReceiver = new ChatMember();
String myCall = this.client.getChatPreferences().getStn_loginCallSign();
if (receiverCallSign.equalsIgnoreCase(myCall)) {
fallbackReceiver.setCallSign(myCall);
} else {
fallbackReceiver.setCallSign(receiverCallSign + "(left)");
}
fallbackReceiver.setCallSign(receiverCallSign + "(left)");
fallbackReceiver.setChatCategory(category);
fallbackReceiver.setAirPlaneReflectInfo(new AirPlaneReflectionInfo());
fallbackReceiver.setAirPlaneReflectInfo(
new AirPlaneReflectionInfo()
);
return fallbackReceiver;
}
@@ -777,6 +947,19 @@ public class MessageBusManagementThread extends Thread {
newMessageArrived));
}
/*
* Detect and store the sender's QRG before any directional-opportunity
* or DX-Cluster processing. A frequency first mentioned in this directed
* message is then immediately available for the resulting spot.
*
* The parser needs only the message text, sender and preferences. The
* receiver does not have to be resolved yet.
*/
smartFrequencyExtraction(
newMessageArrived,
this.client.getChatPreferences());
// TODO: Next: get frequency infos out of name?
if (splittedMessageLine[7].equals("0")) {
// message is not directed to anyone, move it to the cq messages.
@@ -829,7 +1012,11 @@ public class MessageBusManagementThread extends Thread {
versionInfo.setSender(itsMe);
versionInfo.setReceiver(newMessageArrived.getSender());
versionInfo.setMessageText("/CQ " + newMessageArrived.getSender().getCallSign() + " " + ApplicationConstants.AUTOANSWER_PREFIX + " " + "KST4Contest " + " v" + ApplicationConstants.APPLICATION_CURRENT_VERSION + " by DO5AMF");
versionInfo.setChatCategory(newMessageArrived.getChatCategory());
versionInfo.setMessageText("/CQ " + newMessageArrived.getSender().getCallSign()
+ " " + AUTOANSWER_PREFIX
+ " KST4Contest v" + ApplicationConstants.APPLICATION_CURRENT_VERSION
+ " by DO5AMF");
this.client.getMessageTXBus().add(versionInfo);
}
@@ -876,11 +1063,11 @@ public class MessageBusManagementThread extends Thread {
// }
// }
// ==== Unified Autoanswer (Generic + QRG) with Pingpong-Guard + per-Remote Cooldown ====
// ==== Unified auto-answer (generic + QRG) with ping-pong guard and per-remote cooldown ====
final String incomingText = newMessageArrived.getMessageText();
final String incomingLower = (incomingText == null) ? "" : incomingText.toLowerCase(Locale.ROOT);
// 1) Pingpong-security: never ever react to auto generated messages
// Never answer another automatically generated message.
if (!isAutoMessage(newMessageArrived)) {
boolean qrgRequested = false;
@@ -896,24 +1083,17 @@ public class MessageBusManagementThread extends Thread {
boolean genericEnabled = this.client.getChatPreferences().isMsgHandling_autoAnswerEnabled();
// 2) Entscheide, ob überhaupt geantwortet wird (QRG hat Vorrang vor Generic)
// A QRG reply takes precedence over the generic reply.
String payload = null;
if (qrgRequested) {
if (this.client.getChatPreferences().isLoginToSecondChatEnabled()) {
payload = "QRGs: " + this.client.getChatPreferences().getMYQRGFirstCat().getValue()
+ " / " + this.client.getChatPreferences().getMYQRGSecondCat().getValue();
} else {
payload = "QRG is: " + this.client.getChatPreferences().getMYQRGFirstCat().getValue();
}
payload = "QRG is: " + getAutoAnswerQrgForCategory(newMessageArrived.getChatCategory());
} else if (genericEnabled) {
payload = this.client.getChatPreferences().getMessageHandling_autoAnswerTextMainCat();
}
// 3) Cooldown pro Gegenstation: nur wenn DIESER Client jetzt wirklich sendet
// Apply the cooldown only when this client is about to send a reply.
if (payload != null && isAutoAnswerAllowedNow(newMessageArrived)) {
ChatMessage automaticAnswer = new ChatMessage();
@@ -922,15 +1102,15 @@ public class MessageBusManagementThread extends Thread {
automaticAnswer.setSender(itsMe);
automaticAnswer.setReceiver(newMessageArrived.getSender());
automaticAnswer.setChatCategory(newMessageArrived.getChatCategory());
// Prefix fest + nicht entfernbar, damit AutoAuto nicht pingpongt
// The fixed prefix prevents automatic clients from answering each other.
automaticAnswer.setMessageText("/CQ " + newMessageArrived.getSender().getCallSign()
+ " " + AUTOANSWER_PREFIX + " " + payload);
this.client.getMessageTXBus().add(automaticAnswer);
// Cooldown wird NUR hier gesetzt (nicht bei 'message sent by me' Echo),
// damit nur lokale Auto-Sends zählen.
// Record only locally generated replies, not the later server echo.
markLocalAutoAnswerSent(newMessageArrived);
}
}
@@ -1062,9 +1242,6 @@ public class MessageBusManagementThread extends Thread {
exceptionOccured.printStackTrace();
}
// --- Band/QRG recognition (fills ChatMember.knownActiveBands) ---
smartFrequencyExtraction(newMessageArrived, this.client.getChatPreferences());
// TODO: Next: get frequency infos out of name?
} else
@@ -1196,9 +1373,12 @@ public class MessageBusManagementThread extends Thread {
newDXCListSender3.setQra(splittedMessageLine[5]);
ChatMember newDXCListReceiver3 = new ChatMember();
// newDXCListReceiver3.setFrequency(splittedMessageLine[4]);
newDXCListReceiver3.setCallSign(splittedMessageLine[4]);
newDXCListReceiver3.setQra(splittedMessageLine[5]);
/*
* MA format:
* MA|0|epoch|sender|receiver|sender locator|receiver locator|
*/
newDXCListReceiver3.setQra(splittedMessageLine[6]);
dxcMsg3.setSender(newDXCListSender3);
dxcMsg3.setReceiver(newDXCListReceiver3);
@@ -1544,9 +1724,7 @@ public class MessageBusManagementThread extends Thread {
/**
* check if message had been auto generated
* @param msg
* @return
* Returns whether a message carries the fixed marker used for automatic replies.
*/
private boolean isAutoMessage(ChatMessage msg) {
return msg != null
@@ -1554,6 +1732,22 @@ public class MessageBusManagementThread extends Thread {
&& msg.getMessageText().contains(AUTOANSWER_PREFIX);
}
/**
* Returns the configured QRG for the category in which the request was received.
* If the category cannot be resolved, the main category remains the safe fallback.
*/
private String getAutoAnswerQrgForCategory(ChatCategory incomingCategory) {
ChatCategory secondCategory = this.client.getChatCategorySecondChat();
if (incomingCategory != null
&& secondCategory != null
&& incomingCategory.getCategoryNumber() == secondCategory.getCategoryNumber()) {
return this.client.getChatPreferences().getMYQRGSecondCat().getValue();
}
return this.client.getChatPreferences().getMYQRGFirstCat().getValue();
}
private String autoAnswerCooldownKey(ChatMessage incoming) {
String remoteCall = "UNKNOWN";
@@ -1561,13 +1755,16 @@ public class MessageBusManagementThread extends Thread {
remoteCall = incoming.getSender().getCallSign().toUpperCase();
}
int cat = 0; // fallback
if (incoming != null && incoming.getSender() != null && incoming.getSender().getChatCategory() != null) {
cat = incoming.getSender().getChatCategory().getCategoryNumber();
int categoryNumber = 0;
if (incoming != null && incoming.getChatCategory() != null) {
categoryNumber = incoming.getChatCategory().getCategoryNumber();
} else if (incoming != null
&& incoming.getSender() != null
&& incoming.getSender().getChatCategory() != null) {
categoryNumber = incoming.getSender().getChatCategory().getCategoryNumber();
}
// pro Gegenstation + pro Chat-Kategorie (falls derselbe Call in Cat2/Cat3 PMs macht)
return remoteCall + "|" + cat;
return remoteCall + "|" + categoryNumber;
}
private boolean isAutoAnswerAllowedNow(ChatMessage incoming) {
@@ -0,0 +1,81 @@
//package kst4contest.controller;
//
//import kst4contest.model.Band;
//import org.junit.jupiter.api.Test;
//import org.junit.jupiter.params.ParameterizedTest;
//import org.junit.jupiter.params.provider.ValueSource;
//
//import java.util.regex.Matcher;
//import java.util.regex.Pattern;
//
//import static org.junit.jupiter.api.Assertions.assertEquals;
//import static org.junit.jupiter.api.Assertions.assertFalse;
//import static org.junit.jupiter.api.Assertions.assertNotNull;
//import static org.junit.jupiter.api.Assertions.assertNull;
//import static org.junit.jupiter.api.Assertions.assertTrue;
//
//class MessageBusManagementThreadFrequencyContextTest {
//
// private static final Pattern THREE_DIGIT_VALUE =
// Pattern.compile("\\b\\d{3}\\b");
//
// @ParameterizedTest
// @ValueSource(strings = {
// "qrg 210",
// "QRG: 210",
// "freq is 210",
// "frequency = 210",
// "on 210",
// "210 MHz",
// "210 qrg"
// })
// void acceptsBareThreeDigitValueWithFrequencyContext(String messageText) {
// Matcher matcher = findThreeDigitValue(messageText);
//
// assertTrue(
// MessageBusManagementThread
// .hasExplicitBareFrequencyContext(
// messageText,
// matcher.start(),
// matcher.end()
// )
// );
// }
//
// @ParameterizedTest
// @ValueSource(strings = {
// "599",
// "144",
// "serial 210",
// "score 210",
// "worked 210 stations"
// })
// void rejectsBareThreeDigitValueWithoutFrequencyContext(String messageText) {
// Matcher matcher = findThreeDigitValue(messageText);
//
// assertFalse(
// MessageBusManagementThread
// .hasExplicitBareFrequencyContext(
// messageText,
// matcher.start(),
// matcher.end()
// )
// );
// }
//
// @Test
// void resolvesOnlySupportedFallbackPrefixes() {
// assertEquals(Band.B_144, Band.fromPrefix("144"));
// assertEquals(Band.B_432, Band.fromPrefix(" 432 "));
// assertEquals(Band.B_10G, Band.fromPrefix("10368"));
// assertNull(Band.fromPrefix("999"));
// assertNull(Band.fromPrefix(null));
// }
//
// private Matcher findThreeDigitValue(String messageText) {
// Matcher matcher = THREE_DIGIT_VALUE.matcher(messageText);
// assertTrue(matcher.find(), "Test message must contain a three-digit value");
// assertNotNull(matcher.group());
// return matcher;
// }
//}
@@ -0,0 +1,154 @@
package kst4contest.controller;
import java.math.BigDecimal;
import java.util.List;
import java.util.Objects;
import kst4contest.model.AirPlane;
import kst4contest.model.AirPlaneReflectionInfo;
import kst4contest.model.ChatMember;
import kst4contest.model.ChatPreferences;
/**
* Resolves variables used in operator messages, shortcuts, snippets and
* beacons.
*
* <p>Global variables only depend on the local station configuration and can
* therefore be used in every message context. Station variables additionally
* require a selected remote station. Keeping both groups in one resolver
* prevents the send field and the beacon tasks from implementing different
* replacement rules.</p>
*/
public final class MessageVariableResolver {
private static final int SHORT_VALUE_LENGTH = 7;
private final ChatPreferences chatPreferences;
/**
* Creates a resolver backed by the live application preferences.
*
* @param chatPreferences preferences that provide current station values
*/
public MessageVariableResolver(ChatPreferences chatPreferences) {
this.chatPreferences = Objects.requireNonNull(chatPreferences, "chatPreferences");
}
/**
* Resolves variables which do not require a selected remote station.
*
* <p>The replacement is literal rather than regular-expression based.
* Callsigns, locators and frequencies are data, not regular expressions.</p>
*
* @param template text that may contain variables
* @return text with all available global variables resolved, or {@code null}
* when the supplied template is {@code null}
*/
public String resolveGlobalVariables(String template) {
if (template == null) {
return null;
}
String primaryFrequency = valueOrEmpty(chatPreferences.getMYQRGFirstCat().getValue());
String secondaryFrequency = valueOrEmpty(chatPreferences.getMYQRGSecondCat().getValue());
String ownLocator = valueOrEmpty(chatPreferences.getStn_loginLocatorMainCat());
String resolvedText = template;
resolvedText = resolvedText.replace("MYQRGSHORT", abbreviate(primaryFrequency));
resolvedText = resolvedText.replace("MYQRG", primaryFrequency);
resolvedText = resolvedText.replace("SECONDQRG", secondaryFrequency);
resolvedText = resolvedText.replace("MYLOCATORSHORT", abbreviateLocator(ownLocator));
resolvedText = resolvedText.replace("MYLOCATOR", ownLocator);
resolvedText = resolvedText.replace("MYCALL", valueOrEmpty(chatPreferences.getStn_loginCallSign()));
resolvedText = resolvedText.replace("MYQTF", formatHeading(chatPreferences.getActualQTF().getValue().doubleValue()));
return resolvedText;
}
/**
* Resolves global variables and variables derived from a selected station.
*
* <p>If no station is selected, station-specific placeholders remain visible.
* This is intentional: silently removing {@code QRZNAME}, {@code FIRSTAP} or
* {@code SECONDAP} could create a plausible-looking but incomplete message.</p>
*
* @param template text that may contain variables
* @param selectedStation currently selected remote station, may be {@code null}
* @return resolved message text
*/
public String resolveForSelectedStation(String template, ChatMember selectedStation) {
String resolvedText = resolveGlobalVariables(template);
if (resolvedText == null || selectedStation == null) {
return resolvedText;
}
resolvedText = resolvedText.replace("QRZNAME", resolveStationName(selectedStation));
resolvedText = resolvedText.replace("FIRSTAP", resolveFirstAirPlane(selectedStation));
resolvedText = resolvedText.replace("SECONDAP", resolveSecondAirPlane(selectedStation));
return resolvedText;
}
private String resolveStationName(ChatMember selectedStation) {
String stationName = valueOrEmpty(selectedStation.getName()).trim();
if (!stationName.isEmpty()) {
return stationName;
}
return valueOrEmpty(selectedStation.getCallSign());
}
private String resolveFirstAirPlane(ChatMember selectedStation) {
List<AirPlane> risingAirPlanes = getRisingAirPlanes(selectedStation);
if (risingAirPlanes.isEmpty()) {
return "no ap available";
}
AirPlane firstAirPlane = risingAirPlanes.get(0);
return "a " + firstAirPlane.getPotencialDescriptionAsWord()
+ " in " + firstAirPlane.getArrivingDurationMinutes() + " min";
}
private String resolveSecondAirPlane(ChatMember selectedStation) {
List<AirPlane> risingAirPlanes = getRisingAirPlanes(selectedStation);
if (risingAirPlanes.size() < 2) {
return "";
}
AirPlane secondAirPlane = risingAirPlanes.get(1);
return "Next " + secondAirPlane.getPotencialDescriptionAsWord()
+ " in " + secondAirPlane.getArrivingDurationMinutes() + " min";
}
private List<AirPlane> getRisingAirPlanes(ChatMember selectedStation) {
AirPlaneReflectionInfo reflectionInfo = selectedStation.getAirPlaneReflectInfo();
if (reflectionInfo == null || reflectionInfo.getRisingAirplanes() == null) {
return List.of();
}
return reflectionInfo.getRisingAirplanes();
}
private String abbreviate(String value) {
return value.substring(0, Math.min(value.length(), SHORT_VALUE_LENGTH));
}
private String abbreviateLocator(String locator) {
return locator.substring(0, Math.min(locator.length(), 4));
}
private String formatHeading(double headingDegrees) {
if (!Double.isFinite(headingDegrees)) {
return "";
}
return BigDecimal.valueOf(headingDegrees).stripTrailingZeros().toPlainString();
}
private String valueOrEmpty(String value) {
return value == null ? "" : value;
}
}
@@ -1,4 +1,5 @@
package kst4contest.controller;
import kst4contest.logic.BandOpportunityResolver;
import kst4contest.view.map.MapCallsignRawSnapshot;
import java.util.ArrayList;
@@ -168,14 +169,31 @@ public final class ReachabilityService {
selectedSnapshot.lastKnownFrequenciesByBand()
);
if (!Double.isFinite(analysisFrequencyMHz) || analysisFrequencyMHz <= 0.0) {
Band fallbackBand = member == null ? Band.B_144 : resolveAutoBand(member);
analysisFrequencyMHz = resolveAnalysisFrequencyForBand(member, fallbackBand);
Band analysisBand = Band.fromFrequency(analysisFrequencyMHz);
if (analysisBand != null && !isUsableAutomaticBand(member, analysisBand)) {
analysisFrequencyMHz = Double.NaN;
analysisBand = null;
}
Band analysisBand = Band.fromFrequency(analysisFrequencyMHz);
if (analysisBand == null) {
analysisBand = member == null ? Band.B_144 : resolveAutoBand(member);
if (!Double.isFinite(analysisFrequencyMHz)
|| analysisFrequencyMHz <= 0.0
|| analysisBand == null) {
Band fallbackBand = resolveAutoBand(member);
if (fallbackBand == null) {
dispatchFxCallback(
fxCallback,
PathAnalysisResult.waitingForUsableBand(
ownLocator6,
targetLocator6,
selectedSnapshot.callSignRaw()
)
);
return;
}
analysisBand = fallbackBand;
analysisFrequencyMHz = resolveAnalysisFrequencyForBand(member, fallbackBand);
}
PathAnalysisRequest request = buildRequest(
@@ -230,20 +248,60 @@ public final class ReachabilityService {
* @return resolved band
*/
public Band resolveAutoBand(ChatMember member) {
if (member != null && member.getKnownActiveBands() != null && !member.getKnownActiveBands().isEmpty()) {
return member.getKnownActiveBands().keySet().stream()
.filter(Objects::nonNull)
EnumSet<Band> enabledBands = getEnabledStationBands();
if (enabledBands.isEmpty()) {
return null;
}
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(Band.B_144);
.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) {
&& member.getChatCategory().getCategoryNumber() == ChatCategory.MICROWAVE
&& fallbackBands.contains(Band.B_1296)) {
return Band.B_1296;
}
return Band.B_144;
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);
}
/**
@@ -253,22 +311,44 @@ public final class ReachabilityService {
* @return set of enabled bands
*/
public EnumSet<Band> getEnabledStationBands() {
ChatPreferences preferences = chatController.getChatPreferences();
EnumSet<Band> enabledBands = EnumSet.noneOf(Band.class);
return BandOpportunityResolver.getEnabledStationBands(
chatController.getChatPreferences()
);
}
if (preferences == null) {
return enabledBands;
private List<ChatMember> resolveCallsignVariants(ChatMember member) {
if (member == null) {
return List.of();
}
if (preferences.isStn_bandActive144()) enabledBands.add(Band.B_144);
if (preferences.isStn_bandActive432()) enabledBands.add(Band.B_432);
if (preferences.isStn_bandActive1240()) enabledBands.add(Band.B_1296);
if (preferences.isStn_bandActive2300()) enabledBands.add(Band.B_2320);
if (preferences.isStn_bandActive3400()) enabledBands.add(Band.B_3400);
if (preferences.isStn_bandActive5600()) enabledBands.add(Band.B_5760);
if (preferences.isStn_bandActive10G()) enabledBands.add(Band.B_10G);
String rawCall = member.getCallSignRaw() != null
? member.getCallSignRaw()
: member.getCallSign();
return enabledBands;
List<ChatMember> variants = chatController.findActiveChatMembersByRawCall(rawCall);
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);
}
/**
@@ -303,17 +303,19 @@ public class ReadUDPByWintestThread extends Thread {
return null;
}
switch (bandId.trim()) {
case "12": return Band.B_144;
case "14": return Band.B_432;
case "16": return Band.B_1296;
case "17": return Band.B_2320;
case "18": return Band.B_3400;
case "19": return Band.B_5760;
case "20": return Band.B_10G;
case "21": return Band.B_24G;
default: return null;
}
return switch (bandId.trim()) {
case "10" -> Band.B_50;
case "11" -> Band.B_70;
case "12" -> Band.B_144;
case "14" -> Band.B_432;
case "16" -> Band.B_1296;
case "17" -> Band.B_2320;
case "18" -> Band.B_3400;
case "19" -> Band.B_5760;
case "20" -> Band.B_10G;
case "21" -> Band.B_24G;
default -> null;
};
}
/**
@@ -83,6 +83,9 @@ public class ReadUDPbyUCXMessageThread extends Thread {
if (xmlStart < 0) {
xmlStart = rawPacket.indexOf("<contactinfo");
}
if (xmlStart < 0) {
xmlStart = rawPacket.indexOf("<contactreplace");
}
if (xmlStart < 0) {
xmlStart = rawPacket.indexOf("<RadioInfo");
}
@@ -141,6 +144,12 @@ public class ReadUDPbyUCXMessageThread extends Thread {
}
switch (band.trim()) {
case "50":
case "6m":
return Band.B_50;
case "70":
case "4m":
return Band.B_70;
case "144":
case "2m":
return Band.B_144;
@@ -288,14 +297,6 @@ public class ReadUDPbyUCXMessageThread extends Thread {
ChatMember modifyThat = null;
// System.out.println("ReadUDPByUCX, message catched: " + udpMsg);
// String[] threadStatusMessage = new String[2];
// threadStatusMessage = new String[3];
// threadStatusMessage[0] = "on";
// threadStatusMessage[1] = "received message:";
// threadStatusMessage[2] = udpMsg;
ThreadStateMessage threadStateMessage = new ThreadStateMessage(this.ThreadNickName, true, "received Message\n" + udpMsg, false);
callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
@@ -304,7 +305,7 @@ public class ReadUDPbyUCXMessageThread extends Thread {
try {
dbf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
} catch (ParserConfigurationException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
}
@@ -313,10 +314,16 @@ public class ReadUDPbyUCXMessageThread extends Thread {
Document doc = db.parse(new InputSource(new StringReader(udpMsg)));
/**
* case Log-QSO-Packet in ucxlog
* case Log-QSO-Packet in ucxlog / DXLog and compatible
*
*/
NodeList list = doc.getElementsByTagName("contactinfo");
if (list.getLength() == 0) {
list = doc.getElementsByTagName("contactreplace");
//DXlog will send contactreplace instead of contactinfo on clicking "broadcast whole logbook"
}
if (list.getLength() != 0) {
/*
@@ -356,6 +363,20 @@ public class ReadUDPbyUCXMessageThread extends Thread {
Band workedBand = helper_resolveBandFromLoggerBand(band);
switch (band) {
case "50":
case "6m":
{
workedCall.setWorked50(true);
break;
}
case "70":
case "4m":
{
workedCall.setWorked70(true);
break;
}
case "144":
case "2m": //minos contest logger
{
@@ -433,7 +454,13 @@ public class ReadUDPbyUCXMessageThread extends Thread {
modifyThat.setWorked(true);
if (workedCall.isWorked144()) {
if (workedCall.isWorked50()) {
modifyThat.setWorked50(true);
} else if (workedCall.isWorked70()) {
modifyThat.setWorked70(true);
} else if (workedCall.isWorked144()) {
modifyThat.setWorked144(true);
} else if (workedCall.isWorked432()) {
@@ -140,7 +140,9 @@ public final class ScoreService {
controller.getStationMetricsService().snapshot(nowEpochMs, prefs);
// 1) Choose one representative per callsignRaw
Map<String, ChatMember> representativeByCallRaw = chooseRepresentativeMembers(members, lastInbound);
Map<String, List<ChatMember>> variantsByCallRaw = groupMembersByCallRaw(members);
Map<String, ChatMember> representativeByCallRaw =
chooseRepresentativeMembers(variantsByCallRaw, lastInbound);
// 2) Compute score once per callsignRaw
Map<String, Double> scoreByCallRaw = new HashMap<>(representativeByCallRaw.size());
@@ -154,6 +156,7 @@ public final class ScoreService {
double score = priorityCalculator.calculatePriority(
representative,
variantsByCallRaw.getOrDefault(callRaw, List.of(representative)),
prefs,
activeSkeds,
metricsSnapshot,
@@ -163,7 +166,15 @@ public final class ScoreService {
scoreByCallRaw.put(callRaw, score);
preferredCategoryByCallRaw.put(callRaw, representative.getChatCategory());
topAll.add(new TopCandidate(callRaw, representative.getCallSign(), representative.getChatCategory(), score));
if (Double.isFinite(score) && score > 0.0) {
topAll.add(new TopCandidate(
callRaw,
representative.getCallSign(),
representative.getChatCategory(),
score
));
}
}
// 3) Build Top-N
@@ -189,6 +200,21 @@ public final class ScoreService {
});
}
private Map<String, List<ChatMember>> groupMembersByCallRaw(List<ChatMember> members) {
Map<String, List<ChatMember>> byCallRaw = new HashMap<>();
for (ChatMember member : members) {
if (member == null) continue;
String callRaw = normalizeCallRaw(member.getCallSignRaw());
if (callRaw == null || callRaw.isEmpty()) continue;
byCallRaw.computeIfAbsent(callRaw, ignored -> new ArrayList<>()).add(member);
}
return byCallRaw;
}
/**
* Picks one ChatMember object per callsignRaw.
* Preference order:
@@ -196,18 +222,9 @@ public final class ScoreService {
* 2) Most recently active variant (fallback)
*/
private Map<String, ChatMember> chooseRepresentativeMembers(
List<ChatMember> members,
Map<String, List<ChatMember>> byCallRaw,
Map<String, ChatCategory> lastInboundCategoryByCallRaw
) {
Map<String, List<ChatMember>> byCallRaw = new HashMap<>();
for (ChatMember m : members) {
if (m == null) continue;
String callRaw = normalizeCallRaw(m.getCallSignRaw());
if (callRaw == null || callRaw.isEmpty()) continue;
byCallRaw.computeIfAbsent(callRaw, k -> new ArrayList<>()).add(m);
}
Map<String, ChatMember> representative = new HashMap<>(byCallRaw.size());
for (Map.Entry<String, List<ChatMember>> entry : byCallRaw.entrySet()) {
@@ -218,12 +235,11 @@ public final class ScoreService {
ChatMember chosen = null;
if (preferredCat != null) {
for (ChatMember v : variants) {
if (v != null && v.getChatCategory() == preferredCat) {
chosen = v;
break;
}
}
chosen = variants.stream()
.filter(Objects::nonNull)
.filter(v -> isSameChatCategory(v.getChatCategory(), preferredCat))
.max(Comparator.comparingLong(ChatMember::getActivityTimeLastInEpoch))
.orElse(null);
}
if (chosen == null) {
@@ -238,6 +254,14 @@ public final class ScoreService {
return representative;
}
private static boolean isSameChatCategory(ChatCategory left, ChatCategory right) {
return left != null
&& right != null
&& left.getCategoryNumber() == right.getCategoryNumber();
}
/**
* Projects the immutable score snapshot back into ChatMember display fields so
* the normal station table can sort/filter by score without knowing the score
@@ -14,8 +14,8 @@ import java.util.TimerTask;
* The task will be runned out of the singleton ChatController instance in an
* intervall as specified by the Chatpreferences-instance (typically as
* configured in the xml file.
*
*
*
*
* @author prakt
*
*/
@@ -34,22 +34,20 @@ public class ScoreboardUpdateTask extends TimerTask {
Thread.currentThread().setName("BeaconTask");
ChatMessage beaconMSG = new ChatMessage();
String replaceVariables = this.chatController.getChatPreferences().getBcn_beaconTextMainCat();
// replaceVariables = bcn_beaconText;
replaceVariables = replaceVariables.replaceAll("MYQRG", this.chatController.getChatPreferences().getMYQRGFirstCat().getValue());
replaceVariables = replaceVariables.replaceAll("MYCALL", this.chatController.getChatPreferences().getStn_loginCallSign());
replaceVariables = replaceVariables.replaceAll("MYLOCATOR", this.chatController.getChatPreferences().getStn_loginLocatorMainCat());
replaceVariables = replaceVariables.replaceAll("MYQTF", this.chatController.getChatPreferences().getActualQTF().getValue() + "");
MessageVariableResolver variableResolver =
new MessageVariableResolver(this.chatController.getChatPreferences());
String replaceVariables = variableResolver.resolveGlobalVariables(
this.chatController.getChatPreferences().getBcn_beaconTextMainCat()
);
beaconMSG.setMessageText(
"MSG|" + this.chatController.getChatPreferences().getLoginChatCategoryMain().getCategoryNumber() + "|0|" + replaceVariables + "|0|");
beaconMSG.setMessageDirectedToServer(true);
// System.out.println("########### " + replaceVariables);
if (this.chatController.getChatPreferences().isBcn_beaconsEnabledMainCat() ) {
System.out.println(new Utils4KST().time_generateCurrentMMDDhhmmTimeString()
@@ -58,8 +56,8 @@ public class ScoreboardUpdateTask extends TimerTask {
} else {
//do nothing, CQ is disabled
}
}
}
}
@@ -2,6 +2,7 @@ package kst4contest.controller;
import kst4contest.logic.SignalDetector;
import kst4contest.model.ChatPreferences;
import kst4contest.model.ChatMember;
import java.util.ArrayDeque;
import java.util.Deque;
@@ -21,7 +22,7 @@ import java.util.regex.Pattern;
public final class StationMetricsService {
/** /cq <CALL> ... */
private static final Pattern OUTBOUND_CQ_PATTERN = Pattern.compile("(?i)^\\s*/cq\\s+([A-Z0-9/]+)\\b.*");
private static final Pattern OUTBOUND_CQ_PATTERN = Pattern.compile("(?i)^\\s*/cq\\s+([A-Z0-9/-]+)\\b.*");
/** Rolling window timestamps for momentum scoring. */
private static final int MAX_STORED_INBOUND_TIMESTAMPS = 32;
@@ -195,7 +196,7 @@ public final class StationMetricsService {
private static String normalizeCallRaw(String s) {
if (s == null) return null;
return s.trim().toUpperCase();
return ChatMember.normalizeCallSignToBaseCallSign(s);
}
private static final class StationMetrics {
@@ -39,26 +39,63 @@ public class WinTestSkedSender {
}
/**
* Pushes a ContestSked into Win-Test by sending the LOCKSKED / ADDSKED / UNLOCKSKED
* sequence via UDP broadcast.
* Pushes a ContestSked into Win-Test by sending the
* LOCKSKED / ADDSKED / UNLOCKSKED sequence.
*
* @param sked the sked to push
* @param frequencyKHz current operating frequency in kHz (e.g. 144321.0)
* @param notes free-text notes (e.g. "[JO62QM - 123°] sked via KST")
* @param sked sked to push
* @param targetCallsign callsign prepared for Win-Test
* @param frequencyKHz operating frequency in kHz
* @param notes optional notes
* @param mode Win-Test mode ID: 0 for CW, 1 for SSB
*/
public void pushSkedToWinTest(ContestSked sked, double frequencyKHz, String notes, int modeOverride) {
public void pushSkedToWinTest(ContestSked sked,
String targetCallsign,
double frequencyKHz,
String notes,
int mode) {
try {
sendLockSked();
sendAddSked(sked, frequencyKHz, notes, modeOverride);
sendAddSked(
sked,
targetCallsign,
frequencyKHz,
notes,
mode
);
sendUnlockSked();
reportStatus("Sked pushed to WT: " + sked.getTargetCallsign(), false);
System.out.println("[WinTestSkedSender] Sked pushed: " + sked.getTargetCallsign()
+ " at " + frequencyKHz + " kHz, band=" + sked.getBand());
} catch (Exception e) {
reportStatus("ERROR pushing sked: " + e.getMessage(), true);
System.out.println("[WinTestSkedSender] Error pushing sked: " + e.getMessage());
e.printStackTrace();
reportStatus(
"Sked pushed to WT: " + targetCallsign,
false
);
System.out.println(
"[WinTestSkedSender] Sked pushed: "
+ targetCallsign
+ " at "
+ frequencyKHz
+ " kHz, band="
+ sked.getBand()
+ ", mode="
+ mode
);
} catch (Exception exception) {
reportStatus(
"ERROR pushing sked: "
+ exception.getMessage(),
true
);
System.out.println(
"[WinTestSkedSender] Error pushing sked: "
+ exception.getMessage()
);
exception.printStackTrace();
}
}
@@ -86,46 +123,53 @@ public class WinTestSkedSender {
/**
* Sends an ADDSKED message with the sked details.
* <p>
* Win-Test ADDSKED data format (from wtKST):
* <pre>
* {epoch_seconds} {freq_in_0.1kHz} {bandId} {mode} "{callsign}" "{notes}"
* </pre>
* <p>
* Win-Test uses a timestamp reference of 1970-01-01 00:01:00 UTC (60s offset from Unix epoch).
* The C# code adds 60 seconds to compensate.
*
* <p>The wtKST implementation subtracts a reference time of
* 1970-01-01 00:01:00 UTC and subsequently adds 60 seconds. Both
* operations cancel each other out. The transmitted value is therefore
* an ordinary Unix timestamp and must not receive another offset here.</p>
*/
private void sendAddSked(ContestSked sked, double frequencyKHz, String notes, int modeOverride) throws Exception {
// Win-Test timestamp: epoch seconds with 60s offset
long epochSeconds = sked.getSkedTimeEpoch() / 1000;
long wtTimestamp = epochSeconds + 60;
private void sendAddSked(ContestSked sked,
String targetCallsign,
double frequencyKHz,
String notes,
int mode) throws Exception {
// Frequency in 0.1 kHz units (Win-Test convention): multiply kHz by 10
long freqTenthKHz = Math.round(frequencyKHz * 10.0);
long wtTimestamp =
sked.getSkedTimeEpoch() / 1000L;
// Win-Test band ID
int bandId = toWinTestBandId(sked.getBand());
// Frequency in 0.1 kHz units.
long frequencyTenthKHz =
Math.round(frequencyKHz * 10.0);
// Mode: -1 = auto-detect from frequency, 0 = CW, 1 = SSB
int mode;
if (modeOverride >= 0) {
mode = modeOverride;
} else {
mode = isInSsbSegment(frequencyKHz) ? 1 : 0;
}
int bandId =
toWinTestBandId(sked.getBand());
String data = wtTimestamp
+ " " + freqTenthKHz
+ " " + bandId
+ " " + mode
+ " \"" + sked.getTargetCallsign() + "\""
+ " \"" + (notes != null ? notes : "") + "\"";
/*
* Accept only the mode IDs supported by this UI.
* Any unexpected value falls back to SSB.
*/
int winTestMode =
mode == 0
? 0
: 1;
WinTestMessage msg = new WinTestMessage(
String data =
wtTimestamp
+ " " + frequencyTenthKHz
+ " " + bandId
+ " " + winTestMode
+ " \"" + targetCallsign + "\""
+ " \"" + (notes != null ? notes : "") + "\"";
WinTestMessage message = new WinTestMessage(
WinTestMessage.MessageType.ADDSKED,
stationName, "",
data);
sendUdp(msg);
stationName,
"",
data
);
sendUdp(message);
}
/**
@@ -155,6 +199,8 @@ public class WinTestSkedSender {
public static int toWinTestBandId(Band band) {
if (band == null) return 12; // default to 144 MHz
return switch (band) {
case B_50 -> 10;
case B_70 -> 11;
case B_144 -> 12;
case B_432 -> 14;
case B_1296 -> 16;
@@ -166,18 +212,6 @@ public class WinTestSkedSender {
};
}
/**
* Very simple SSB segment heuristic.
* A more complete implementation would check actual mode from Win-Test STATUS.
*/
private boolean isInSsbSegment(double frequencyKHz) {
// SSB segments (kHz ranges)
if (frequencyKHz >= 144300 && frequencyKHz <= 144399) return true; // 2m SSB
if (frequencyKHz >= 432200 && frequencyKHz <= 432399) return true; // 70cm SSB
if (frequencyKHz >= 1296200 && frequencyKHz <= 1296399) return true; // 23cm SSB
return false;
}
private void reportStatus(String text, boolean isError) {
if (callback != null) {
callback.onThreadStatus(THREAD_NICKNAME,
@@ -98,6 +98,8 @@ public final class WorkedGrossFieldCache {
if (member.isWorked3400()) addWorked(Band.B_3400, locator);
if (member.isWorked5600()) addWorked(Band.B_5760, locator);
if (member.isWorked10G()) addWorked(Band.B_10G, locator);
if (member.isWorked50()) addWorked(Band.B_50, locator);
if (member.isWorked70()) addWorked(Band.B_70, locator);
}
}
@@ -0,0 +1,264 @@
package kst4contest.logic;
import kst4contest.model.Band;
import kst4contest.model.ChatMember;
import kst4contest.model.ChatPreferences;
import java.util.Collection;
import java.util.Collections;
import java.util.EnumMap;
import java.util.EnumSet;
import java.util.Map;
import java.util.regex.Pattern;
/**
* Resolves band availability and band-upgrade opportunities from one or more
* active {@link ChatMember} variants of the same base callsign.
*
* <p>The resolver deliberately separates a band hint from an exact frequency:
* {@code knownActiveBands} remains the source for detected QRGs with timestamps,
* while the station name may add a band without inventing a frequency.</p>
*
* <p>A manual NOT-QRV flag always overrides automatic evidence. Worked flags are
* evaluated separately because an offered band may still be useful for display,
* even when it is no longer a band-upgrade opportunity.</p>
*/
public final class BandOpportunityResolver {
public static final long RECENT_DYNAMIC_EVIDENCE_MAX_AGE_MS = 30L * 60L * 1000L;
private static final Map<Band, Pattern> STATION_NAME_BAND_PATTERNS = createStationNameBandPatterns();
private BandOpportunityResolver() {
}
/**
* Resolves the common band state using the application-wide 30-minute window
* for frequency evidence. Name-derived band hints remain valid while the
* ChatMember is present in the active chat model.
*/
public static Resolution resolve(Collection<ChatMember> variants, long nowEpochMs) {
return resolve(variants, nowEpochMs, RECENT_DYNAMIC_EVIDENCE_MAX_AGE_MS);
}
/**
* Resolves offered, worked and manually excluded bands across all supplied
* category/callsign variants.
*/
public static Resolution resolve(Collection<ChatMember> variants,
long nowEpochMs,
long dynamicEvidenceMaxAgeMs) {
EnumSet<Band> offeredBands = EnumSet.noneOf(Band.class);
EnumSet<Band> workedBands = EnumSet.noneOf(Band.class);
EnumSet<Band> notQrvBands = EnumSet.noneOf(Band.class);
if (variants == null) {
return new Resolution(offeredBands, workedBands, notQrvBands);
}
for (ChatMember member : variants) {
if (member == null) {
continue;
}
collectRecentFrequencyBands(
member,
offeredBands,
nowEpochMs,
dynamicEvidenceMaxAgeMs
);
offeredBands.addAll(detectBandsFromStationName(member.getName()));
collectWorkedBands(member, workedBands);
collectNotQrvBands(member, notQrvBands);
}
return new Resolution(offeredBands, workedBands, notQrvBands);
}
/**
* Returns the bands enabled in the local station setup. Bands above 10 GHz
* remain excluded because the current preferences do not provide active-band
* flags for them.
*/
public static EnumSet<Band> getEnabledStationBands(ChatPreferences preferences) {
EnumSet<Band> enabledBands = EnumSet.noneOf(Band.class);
if (preferences == null) {
return enabledBands;
}
if (preferences.isStn_bandActive50()) enabledBands.add(Band.B_50);
if (preferences.isStn_bandActive70()) enabledBands.add(Band.B_70);
if (preferences.isStn_bandActive144()) enabledBands.add(Band.B_144);
if (preferences.isStn_bandActive432()) enabledBands.add(Band.B_432);
if (preferences.isStn_bandActive1240()) enabledBands.add(Band.B_1296);
if (preferences.isStn_bandActive2300()) enabledBands.add(Band.B_2320);
if (preferences.isStn_bandActive3400()) enabledBands.add(Band.B_3400);
if (preferences.isStn_bandActive5600()) enabledBands.add(Band.B_5760);
if (preferences.isStn_bandActive10G()) enabledBands.add(Band.B_10G);
return enabledBands;
}
/**
* Detects explicit amateur-band designators in a station name.
*
* <p>The boundary rules are intentionally stricter than simple token splitting.
* In particular, the trailing {@code 2} in {@code 1.2 cm} must not be mistaken
* for the 2 m band.</p>
*/
public static EnumSet<Band> detectBandsFromStationName(String stationName) {
EnumSet<Band> detectedBands = EnumSet.noneOf(Band.class);
if (stationName == null || stationName.isBlank()) {
return detectedBands;
}
for (Map.Entry<Band, Pattern> entry : STATION_NAME_BAND_PATTERNS.entrySet()) {
if (entry.getValue().matcher(stationName).find()) {
detectedBands.add(entry.getKey());
}
}
return detectedBands;
}
private static void collectRecentFrequencyBands(ChatMember member,
EnumSet<Band> target,
long nowEpochMs,
long dynamicEvidenceMaxAgeMs) {
if (member.getKnownActiveBands() == null || member.getKnownActiveBands().isEmpty()) {
return;
}
for (Map.Entry<Band, ChatMember.ActiveFrequencyInfo> entry
: member.getKnownActiveBands().entrySet()) {
Band band = entry.getKey();
ChatMember.ActiveFrequencyInfo info = entry.getValue();
if (band == null || info == null) {
continue;
}
long ageMs = nowEpochMs - info.timestampEpoch;
boolean ageAccepted = dynamicEvidenceMaxAgeMs <= 0L
? ageMs >= 0L
: ageMs >= 0L && ageMs <= dynamicEvidenceMaxAgeMs;
if (ageAccepted) {
target.add(band);
}
}
}
private static void collectWorkedBands(ChatMember member, EnumSet<Band> target) {
if (member.isWorked50()) target.add(Band.B_50);
if (member.isWorked70()) target.add(Band.B_70);
if (member.isWorked144()) target.add(Band.B_144);
if (member.isWorked432()) target.add(Band.B_432);
if (member.isWorked1240()) target.add(Band.B_1296);
if (member.isWorked2300()) target.add(Band.B_2320);
if (member.isWorked3400()) target.add(Band.B_3400);
if (member.isWorked5600()) target.add(Band.B_5760);
if (member.isWorked10G()) target.add(Band.B_10G);
if (member.isWorked24G()) target.add(Band.B_24G);
}
private static void collectNotQrvBands(ChatMember member, EnumSet<Band> target) {
if (!member.isQrv50()) target.add(Band.B_50);
if (!member.isQrv70()) target.add(Band.B_70);
if (!member.isQrv144()) target.add(Band.B_144);
if (!member.isQrv432()) target.add(Band.B_432);
if (!member.isQrv1240()) target.add(Band.B_1296);
if (!member.isQrv2300()) target.add(Band.B_2320);
if (!member.isQrv3400()) target.add(Band.B_3400);
if (!member.isQrv5600()) target.add(Band.B_5760);
if (!member.isQrv10G()) target.add(Band.B_10G);
// There is currently no persisted NOT-QRV flag for 24 GHz.
}
private static Map<Band, Pattern> createStationNameBandPatterns() {
Map<Band, Pattern> patterns = new EnumMap<>(Band.class);
// Bare "70" and bare "6" are already claimed by the 70cm/6cm shorthand below
// (their "CM" suffix is optional), so 4m/6m must require an explicit MHz/"M"
// suffix here to avoid misreading a cm-band shorthand as 70/50 MHz.
patterns.put(Band.B_50, bandPattern("50(?:\\s*MHZ)?|6\\s*M"));
patterns.put(Band.B_70, bandPattern("70\\s*MHZ|4\\s*M"));
patterns.put(Band.B_144, bandPattern("144(?:\\s*MHZ)?|2(?:\\s*M)?"));
patterns.put(Band.B_432, bandPattern("432(?:\\s*MHZ)?|70(?:\\s*CM)?"));
patterns.put(Band.B_1296, bandPattern("1296(?:\\s*MHZ)?|23(?:\\s*CM)?"));
patterns.put(Band.B_2320, bandPattern("(?:2300|2320)(?:\\s*MHZ)?|13(?:\\s*CM)?"));
patterns.put(Band.B_3400, bandPattern("3400(?:\\s*MHZ)?|9(?:\\s*CM)?"));
patterns.put(Band.B_5760, bandPattern("(?:5600|5760)(?:\\s*MHZ)?|6(?:\\s*CM)?"));
patterns.put(Band.B_10G, bandPattern("10368(?:\\s*MHZ)?|10\\s*G(?:HZ)?|3(?:\\s*CM)?"));
patterns.put(Band.B_24G, bandPattern("24048(?:\\s*MHZ)?|24\\s*G(?:HZ)?|1[.,]2(?:\\s*CM)?"));
return Collections.unmodifiableMap(patterns);
}
private static Pattern bandPattern(String alternatives) {
return Pattern.compile(
"(?<![A-Z0-9.,])(?:" + alternatives + ")(?![A-Z0-9.,])",
Pattern.CASE_INSENSITIVE
);
}
/** Immutable result of one callsign-wide band resolution. */
public static final class Resolution {
private final EnumSet<Band> offeredBands;
private final EnumSet<Band> workedBands;
private final EnumSet<Band> notQrvBands;
private Resolution(EnumSet<Band> offeredBands,
EnumSet<Band> workedBands,
EnumSet<Band> notQrvBands) {
this.offeredBands = copyOf(offeredBands);
this.workedBands = copyOf(workedBands);
this.notQrvBands = copyOf(notQrvBands);
}
/** Returns all recent/name-derived bands before NOT-QRV is applied. */
public EnumSet<Band> getOfferedBands() {
return copyOf(offeredBands);
}
public EnumSet<Band> getWorkedBands() {
return copyOf(workedBands);
}
public EnumSet<Band> getNotQrvBands() {
return copyOf(notQrvBands);
}
/** Returns offered bands after manual NOT-QRV exclusions. */
public EnumSet<Band> getAvailableBands() {
EnumSet<Band> availableBands = copyOf(offeredBands);
availableBands.removeAll(notQrvBands);
return availableBands;
}
/** Returns offered, QRV, enabled and not-yet-worked bands. */
public EnumSet<Band> getUnworkedEnabledBands(EnumSet<Band> enabledBands) {
EnumSet<Band> opportunities = getAvailableBands();
if (enabledBands == null || enabledBands.isEmpty()) {
opportunities.clear();
return opportunities;
}
opportunities.retainAll(enabledBands);
opportunities.removeAll(workedBands);
return opportunities;
}
public boolean hasBandEvidence() {
return !offeredBands.isEmpty();
}
private static EnumSet<Band> copyOf(EnumSet<Band> source) {
return source == null || source.isEmpty()
? EnumSet.noneOf(Band.class)
: EnumSet.copyOf(source);
}
}
}
@@ -3,9 +3,9 @@ package kst4contest.logic;
import kst4contest.controller.StationMetricsService;
import kst4contest.model.*;
import java.util.Collection;
import java.util.EnumSet;
import java.util.List;
import java.util.Map;
/**
* Priority score calculation (off FX-thread).
@@ -16,10 +16,8 @@ import java.util.Map;
*/
public class PriorityCalculator {
/** Max age for "known active bands" (derived from chat history). */
private static final long RX_BANDS_MAX_AGE_MS = 30L * 60L * 1000L; // 30 minutes
public double calculatePriority(ChatMember member,
Collection<ChatMember> callsignVariants,
ChatPreferences prefs,
List<ContestSked> activeSkeds,
StationMetricsService.Snapshot metricsSnapshot,
@@ -33,41 +31,51 @@ public class PriorityCalculator {
// --------------------------------------------------------------------
// 1) HARD FILTER: reachable hardware + "already worked on all possible bands"
// --------------------------------------------------------------------
// --------------------------------------------------------------------
// 1) HARD FILTER: reachable hardware + "already worked on all possible bands"
// --------------------------------------------------------------------
EnumSet<Band> myEnabledBands = getMyEnabledBands(prefs);
Collection<ChatMember> variants = callsignVariants == null || callsignVariants.isEmpty()
? List.of(member)
: callsignVariants;
// "worked" for scoring is derived ONLY from per-band flags (worked144/432/...)
// IMPORTANT: ChatMember.worked is UI-only and NOT used in scoring.
EnumSet<Band> workedBandsForScoring = getWorkedBands(member);
BandOpportunityResolver.Resolution bandResolution =
BandOpportunityResolver.resolve(variants, nowEpochMs);
EnumSet<Band> myEnabledBands =
BandOpportunityResolver.getEnabledStationBands(prefs);
// ChatMember.worked remains UI-only. Scoring uses only per-band worked flags.
EnumSet<Band> workedBandsForScoring = bandResolution.getWorkedBands();
// Remaining bands that are:
// - recently offered by the station (from knownActiveBands history)
// - enabled at our station
// - NOT worked yet (per-band flags)
// If we do not know offered bands (history empty), this remains empty.
EnumSet<Band> unworkedPossible = EnumSet.noneOf(Band.class);
EnumSet<Band> stationOfferedBands = getStationOfferedBandsFromHistory(member, nowEpochMs);
EnumSet<Band> stationOfferedBands = bandResolution.getOfferedBands();
EnumSet<Band> stationAvailableBands = bandResolution.getAvailableBands();
EnumSet<Band> possibleBands = stationOfferedBands.isEmpty()
? EnumSet.noneOf(Band.class) // unknown => don't hard-filter
: EnumSet.copyOf(stationOfferedBands);
? EnumSet.noneOf(Band.class)
: EnumSet.copyOf(stationAvailableBands);
if (!possibleBands.isEmpty()) {
if (!stationOfferedBands.isEmpty()) {
possibleBands.retainAll(myEnabledBands);
if (possibleBands.isEmpty()) {
// We know their bands, but none of them are enabled at our station.
// Known bands are disabled locally or manually marked NOT QRV.
return 0.0;
}
unworkedPossible = EnumSet.copyOf(possibleBands);
unworkedPossible.removeAll(workedBandsForScoring);
// If already worked on all possible bands => no priority on them anymore (contest logic).
if (unworkedPossible.isEmpty()) {
return 0.0;
}
} else {
/*
* Missing band evidence is not automatically negative. A complete manual
* NOT-QRV exclusion is different: if every enabled own band is excluded,
* this station cannot be a current contest candidate.
*/
EnumSet<Band> notExplicitlyExcluded = EnumSet.copyOf(myEnabledBands);
notExplicitlyExcluded.removeAll(bandResolution.getNotQrvBands());
if (!myEnabledBands.isEmpty() && notExplicitlyExcluded.isEmpty()) {
return 0.0;
}
}
// --------------------------------------------------------------------
@@ -225,46 +233,6 @@ public class PriorityCalculator {
return Math.max(0.0, score);
}
private static EnumSet<Band> getMyEnabledBands(ChatPreferences prefs) {
EnumSet<Band> out = EnumSet.noneOf(Band.class);
if (prefs.isStn_bandActive144()) out.add(Band.B_144);
if (prefs.isStn_bandActive432()) out.add(Band.B_432);
if (prefs.isStn_bandActive1240()) out.add(Band.B_1296);
if (prefs.isStn_bandActive2300()) out.add(Band.B_2320);
if (prefs.isStn_bandActive3400()) out.add(Band.B_3400);
if (prefs.isStn_bandActive5600()) out.add(Band.B_5760);
if (prefs.isStn_bandActive10G()) out.add(Band.B_10G);
return out;
}
private static EnumSet<Band> getStationOfferedBandsFromHistory(ChatMember member, long nowEpochMs) {
EnumSet<Band> out = EnumSet.noneOf(Band.class);
Map<Band, ChatMember.ActiveFrequencyInfo> map = member.getKnownActiveBands();
if (map == null || map.isEmpty()) return out;
for (Map.Entry<Band, ChatMember.ActiveFrequencyInfo> e : map.entrySet()) {
if (e == null || e.getKey() == null || e.getValue() == null) continue;
long age = nowEpochMs - e.getValue().timestampEpoch;
if (age <= RX_BANDS_MAX_AGE_MS) {
out.add(e.getKey());
}
}
return out;
}
private static EnumSet<Band> getWorkedBands(ChatMember member) {
EnumSet<Band> out = EnumSet.noneOf(Band.class);
if (member.isWorked144()) out.add(Band.B_144);
if (member.isWorked432()) out.add(Band.B_432);
if (member.isWorked1240()) out.add(Band.B_1296);
if (member.isWorked2300()) out.add(Band.B_2320);
if (member.isWorked3400()) out.add(Band.B_3400);
if (member.isWorked5600()) out.add(Band.B_5760);
if (member.isWorked10G()) out.add(Band.B_10G);
if (member.isWorked24G()) out.add(Band.B_24G);
return out;
}
private static int findNextAirplaneArrivingMinutes(AirPlaneReflectionInfo apInfo) {
try {
if (apInfo.getRisingAirplanes() == null || apInfo.getRisingAirplanes().isEmpty()) return -1;
+33
View File
@@ -5,6 +5,8 @@ package kst4contest.model;
* Used for plausibility checks in the Smart Parser.
*/
public enum Band {
B_50(50.000, 54.000, "50"),
B_70(70.000, 70.500, "70"),
B_144(144.000, 146.000, "144"),
B_432(432.000, 434.000, "432"),
B_1296(1296.000, 1298.000, "1296"),
@@ -29,6 +31,35 @@ public enum Band {
return prefix;
}
/**
* Resolves a configured MHz prefix to one of the bands supported by the
* frequency parser.
*
* <p>The former free-text preference accepted arbitrary numeric values even
* though only prefixes represented by this enum can be used for a plausible
* frequency. Keeping the lookup here gives the UI and the parser one common
* definition of a valid fallback band.</p>
*
* @param prefix configured MHz prefix, for example {@code 144} or {@code 10368}
* @return matching band, or {@code null} if the prefix is not supported
*/
public static Band fromPrefix(String prefix) {
if (prefix == null) {
return null;
}
String normalizedPrefix = prefix.trim();
for (Band band : values()) {
if (band.prefix.equals(normalizedPrefix)) {
return band;
}
}
return null;
}
/**
* Returns the lower edge used as practical analysis frequency when only the band
* is known. This keeps the batch reachability calculation deterministic.
@@ -46,6 +77,8 @@ public enum Band {
*/
public String getDisplayLabel() {
switch (this) {
case B_50: return "50";
case B_70: return "70";
case B_144: return "144";
case B_432: return "432";
case B_1296: return "1296";
@@ -26,9 +26,16 @@ public class ChatMember {
String name;
String callSignRaw; //without -2 or -70 etc.
/**
* A directional opportunity inferred from a directed chat message remains
* relevant for five minutes. The timestamp is used instead of a permanent
* boolean so an old antenna-direction assumption cannot remain visible
* indefinitely.
*/
static final long DIRECTION_OPPORTUNITY_VALIDITY_MILLIS = 5L * 60L * 1000L;
private volatile long directionOpportunityValidUntilEpochMs;
boolean isInAngleAndRange; //if he tries a sked in my dir, he is in range, will process that in the messages
// String frequency; // last known qrg of the station
@@ -65,6 +72,8 @@ public class ChatMember {
/**
* Chatmember is qrv at all band except we initialize anything other, depending to user entry
*/
boolean qrv50 = true;
boolean qrv70 = true;
boolean qrv144 = true;
boolean qrv432 = true;
boolean qrv1240 = true;
@@ -108,12 +117,37 @@ public class ChatMember {
this.lastFlagsChangeEpochMs = lastFlagsChangeEpochMs;
}
/**
* Returns whether the most recently inferred directional opportunity is
* still valid.
*
* @return {@code true} until the five-minute validity period has expired
*/
public boolean isInAngleAndRange() {
return isInAngleAndRange;
return isInAngleAndRangeAt(System.currentTimeMillis());
}
/**
* Time-aware variant used by the public getter and by unit tests.
*
* @param nowEpochMs time against which the validity is checked
* @return {@code true} while the stored validity timestamp is still in the future
*/
boolean isInAngleAndRangeAt(long nowEpochMs) {
return directionOpportunityValidUntilEpochMs > nowEpochMs;
}
/**
* Starts a new five-minute validity period or removes the current
* directional opportunity immediately.
*
* @param inAngleAndRange {@code true} for a newly detected opportunity;
* {@code false} to clear it
*/
public void setInAngleAndRange(boolean inAngleAndRange) {
isInAngleAndRange = inAngleAndRange;
directionOpportunityValidUntilEpochMs = inAngleAndRange
? System.currentTimeMillis() + DIRECTION_OPPORTUNITY_VALIDITY_MILLIS
: 0L;
}
public AirPlaneReflectionInfo getAirPlaneReflectInfo() {
@@ -196,6 +230,22 @@ public class ChatMember {
worked10G = worked10g;
}
public boolean isQrv50() {
return qrv50;
}
public void setQrv50(boolean qrv50) {
this.qrv50 = qrv50;
}
public boolean isQrv70() {
return qrv70;
}
public void setQrv70(boolean qrv70) {
this.qrv70 = qrv70;
}
public boolean isQrv144() {
return qrv144;
}
@@ -575,6 +625,8 @@ public class ChatMember {
public void resetQRVInformationAtAllBands() {
this.setQrvAny(true);
this.setQrv50(true);
this.setQrv70(true);
this.setQrv144(true);
this.setQrv432(true);
this.setQrv1240(true);
@@ -0,0 +1,34 @@
package kst4contest.model;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertFalse;
import static org.junit.jupiter.api.Assertions.assertTrue;
class ChatMemberDirectionOpportunityTest {
@Test
void directionalOpportunityExpiresAfterConfiguredValidityPeriod() {
ChatMember member = new ChatMember();
member.setInAngleAndRange(true);
long afterActivationEpochMs = System.currentTimeMillis();
assertTrue(member.isInAngleAndRangeAt(afterActivationEpochMs));
assertFalse(member.isInAngleAndRangeAt(
afterActivationEpochMs
+ ChatMember.DIRECTION_OPPORTUNITY_VALIDITY_MILLIS
+ 1L));
}
@Test
void directionalOpportunityCanBeClearedImmediately() {
ChatMember member = new ChatMember();
member.setInAngleAndRange(true);
assertTrue(member.isInAngleAndRange());
member.setInAngleAndRange(false);
assertFalse(member.isInAngleAndRange());
}
}
@@ -50,7 +50,7 @@ public class ChatPreferences {
* Reading must stay backwards compatible: missing/unknown tags should fall back to defaults.
*/
// private static final int CONFIG_VERSION = 2;
public static final int CONFIG_VERSION = 4;
public static final int CONFIG_VERSION = 5;
// Prefer writing tag names that mirror variable names (human readable). Keep legacy tags for compatibility.
private static final String TAG_CONFIG_VERSION = "configVersion";
@@ -197,6 +197,8 @@ public class ChatPreferences {
boolean loginToSecondChatEnabled;
DoubleProperty actualQTF = new SimpleDoubleProperty(360); // will be updated by user at runtime!
boolean stn_bandActive50;
boolean stn_bandActive70;
boolean stn_bandActive144;
boolean stn_bandActive432;
boolean stn_bandActive1240;
@@ -222,7 +224,7 @@ public class ChatPreferences {
boolean logsynch_wintestNetworkListenerEnabled = true; // default true = bisheriges Verhalten
String logsynch_wintestNetworkBroadcastAddress = "255.255.255.255"; // UDP broadcast address for sending to Win-Test
boolean logsynch_wintestNetworkSkedPushEnabled = false; // push SKEDs to Win-Test via UDP
String logsynch_wintestSkedMode = "SSB"; // CW, SSB or AUTO
String logsynch_wintestSkedMode = "SSB"; // Supported values: SSB or CW
boolean logsynch_wintestQrgSyncEnabled = true; // sync QRG from Win-Test STATUS packet
boolean logsynch_wintestUsePassQrg = false; // use pass frequency instead of main QRG from STATUS packet
@@ -332,9 +334,12 @@ public class ChatPreferences {
boolean guiOptions_defaultFilterPmToMe;
boolean guiOptions_defaultFilterPmToOther;
boolean guiOptions_defaultFilterPublicMsgs;
boolean guiOptions_showGrossFieldWorkedHintInBandColumns = true; // show "o" (grid square already worked on this band) in the band columns
boolean guiOptions_showFreshCallHintInBandColumns = true; // show "a" (band available, call not worked on any band yet) instead of always "B+" in the band columns
private double[] GUIstationMapStageSceneSizeHW = new double[] { 1000, 800 };
private double[] GUIstationMapStagePositionXY = new double[] { Double.NaN, Double.NaN };
private boolean GUIstationMapPathAnalysisVisible = true;
/*********************************************************************************
@@ -631,6 +636,14 @@ public class ChatPreferences {
this.GUIstationMapStagePositionXY = GUIstationMapStagePositionXY;
}
public boolean isGUIstationMapPathAnalysisVisible() {
return GUIstationMapPathAnalysisVisible;
}
public void setGUIstationMapPathAnalysisVisible(boolean GUIstationMapPathAnalysisVisible) {
this.GUIstationMapPathAnalysisVisible = GUIstationMapPathAnalysisVisible;
}
public boolean isGuiOptions_defaultFilterNothing() {
return guiOptions_defaultFilterNothing;
}
@@ -647,6 +660,22 @@ public class ChatPreferences {
this.guiOptions_defaultFilterPmToMe = guiOptions_defaultFilterPmToMe;
}
public boolean isGuiOptions_showGrossFieldWorkedHintInBandColumns() {
return guiOptions_showGrossFieldWorkedHintInBandColumns;
}
public void setGuiOptions_showGrossFieldWorkedHintInBandColumns(boolean guiOptions_showGrossFieldWorkedHintInBandColumns) {
this.guiOptions_showGrossFieldWorkedHintInBandColumns = guiOptions_showGrossFieldWorkedHintInBandColumns;
}
public boolean isGuiOptions_showFreshCallHintInBandColumns() {
return guiOptions_showFreshCallHintInBandColumns;
}
public void setGuiOptions_showFreshCallHintInBandColumns(boolean guiOptions_showFreshCallHintInBandColumns) {
this.guiOptions_showFreshCallHintInBandColumns = guiOptions_showFreshCallHintInBandColumns;
}
public boolean isGuiOptions_defaultFilterPmToOther() {
return guiOptions_defaultFilterPmToOther;
}
@@ -1486,6 +1515,14 @@ public class ChatPreferences {
Element stn_bandActive50 = doc.createElement("stn_bandActive50");
stn_bandActive50.setTextContent(this.stn_bandActive50+"");
station.appendChild(stn_bandActive50);
Element stn_bandActive70 = doc.createElement("stn_bandActive70");
stn_bandActive70.setTextContent(this.stn_bandActive70+"");
station.appendChild(stn_bandActive70);
Element stn_bandActive144 = doc.createElement("stn_bandActive144");
stn_bandActive144.setTextContent(this.stn_bandActive144+"");
station.appendChild(stn_bandActive144);
@@ -1935,6 +1972,14 @@ public class ChatPreferences {
guiOptions_defaultFilterPublicMsgs.setTextContent(this.isGuiOptions_defaultFilterPublicMsgs()+"");
guiSaveableOptions.appendChild(guiOptions_defaultFilterPublicMsgs);
Element guiOptions_showGrossFieldWorkedHintInBandColumns = doc.createElement("guiOptions_showGrossFieldWorkedHintInBandColumns");
guiOptions_showGrossFieldWorkedHintInBandColumns.setTextContent(this.isGuiOptions_showGrossFieldWorkedHintInBandColumns()+"");
guiSaveableOptions.appendChild(guiOptions_showGrossFieldWorkedHintInBandColumns);
Element guiOptions_showFreshCallHintInBandColumns = doc.createElement("guiOptions_showFreshCallHintInBandColumns");
guiOptions_showFreshCallHintInBandColumns.setTextContent(this.isGuiOptions_showFreshCallHintInBandColumns()+"");
guiSaveableOptions.appendChild(guiOptions_showFreshCallHintInBandColumns);
Element guiOptions_darkModeActive = doc.createElement("guiOptions_darkModeActive");
guiOptions_darkModeActive.setTextContent(this.GUI_darkModeActive + "");
guiSaveableOptions.appendChild(guiOptions_darkModeActive);
@@ -2012,6 +2057,12 @@ public class ChatPreferences {
);
guiOptions.appendChild(GUIstationMapStagePositionXY);
Element GUIstationMapPathAnalysisVisible = doc.createElement("GUIstationMapPathAnalysisVisible");
GUIstationMapPathAnalysisVisible.setTextContent(
String.valueOf(this.isGUIstationMapPathAnalysisVisible())
);
guiOptions.appendChild(GUIstationMapPathAnalysisVisible);
/****************************************************************************************
****************************** now write this XML! *************************************
****************************************************************************************/
@@ -2213,6 +2264,8 @@ public class ChatPreferences {
);
// Band activity flags (introduced later; if missing -> keep defaults)
stn_bandActive50 = getBoolean(stationEl, stn_bandActive50, "stn_bandActive50");
stn_bandActive70 = getBoolean(stationEl, stn_bandActive70, "stn_bandActive70");
stn_bandActive144 = getBoolean(stationEl, stn_bandActive144, "stn_bandActive144");
stn_bandActive432 = getBoolean(stationEl, stn_bandActive432, "stn_bandActive432");
stn_bandActive1240 = getBoolean(stationEl, stn_bandActive1240, "stn_bandActive1240");
@@ -2385,8 +2438,11 @@ public class ChatPreferences {
notify_noReplyPenaltyMinutes = noReply;
}
Integer momentum = getInt(notificationsEl, 666, "notify_momentumWindowSeconds");
if (momentum != null) {
Integer momentum = getInt(
notificationsEl,
notify_momentumWindowSeconds,
"notify_momentumWindowSeconds"
); if (momentum != null) {
notify_momentumWindowSeconds = momentum;
}
@@ -2692,6 +2748,14 @@ public class ChatPreferences {
messageHandling_autoAnswerEnabledSecondCat,
"messageHandling_autoAnswerEnabledSecondCat",
"autoAnswerEnabledSecondCat");
/*
* The user interface intentionally exposes one shared generic auto-answer
* setting for both chat categories. Keep the legacy second-category XML
* fields synchronized so existing configuration files remain compatible.
*/
messageHandling_autoAnswerTextSecondCat = messageHandling_autoAnswerTextMainCat;
messageHandling_autoAnswerEnabledSecondCat = messageHandling_autoAnswerEnabled;
}
@@ -2734,6 +2798,17 @@ public class ChatPreferences {
this.getGUIstationMapStagePositionXY()
);
/*
* Files written before config version 5 do not contain this value.
* Keep the default true in that case so existing users discover the
* path-analysis feature before choosing to hide it themselves.
*/
this.setGUIstationMapPathAnalysisVisible(getBoolean(
element,
this.isGUIstationMapPathAnalysisVisible(),
"GUIstationMapPathAnalysisVisible"
));
// Splitpane divider positions
String s1 = getText(element, null, "GUIselectedCallSignSplitPane_dividerposition");
if (s1 != null) {
@@ -2807,6 +2882,8 @@ public class ChatPreferences {
this.setGuiOptions_defaultFilterPmToMe(getBoolean(guiSaveableOptionsEl, this.isGuiOptions_defaultFilterPmToMe(), "guiOptions_defaultFilterPmToMe"));
this.setGuiOptions_defaultFilterPmToOther(getBoolean(guiSaveableOptionsEl, this.isGuiOptions_defaultFilterPmToOther(), "guiOptions_defaultFilterPmToOther"));
this.setGuiOptions_defaultFilterPublicMsgs(getBoolean(guiSaveableOptionsEl, this.isGuiOptions_defaultFilterPublicMsgs(), "guiOptions_defaultFilterPublicMsgs"));
this.setGuiOptions_showGrossFieldWorkedHintInBandColumns(getBoolean(guiSaveableOptionsEl, this.isGuiOptions_showGrossFieldWorkedHintInBandColumns(), "guiOptions_showGrossFieldWorkedHintInBandColumns"));
this.setGuiOptions_showFreshCallHintInBandColumns(getBoolean(guiSaveableOptionsEl, this.isGuiOptions_showFreshCallHintInBandColumns(), "guiOptions_showFreshCallHintInBandColumns"));
// Added in later versions: dark mode flags
this.GUI_darkModeActive = getBoolean(guiSaveableOptionsEl, this.GUI_darkModeActive, "guiOptions_darkModeActive");
@@ -2860,6 +2937,22 @@ public class ChatPreferences {
return result;
}
public boolean isStn_bandActive50() {
return stn_bandActive50;
}
public void setStn_bandActive50(boolean stn_bandActive50) {
this.stn_bandActive50 = stn_bandActive50;
}
public boolean isStn_bandActive70() {
return stn_bandActive70;
}
public void setStn_bandActive70(boolean stn_bandActive70) {
this.stn_bandActive70 = stn_bandActive70;
}
public boolean isStn_bandActive144() {
return stn_bandActive144;
}
@@ -3,25 +3,58 @@ package kst4contest.model;
/**
* Represents a scheduled event or an AirScout opportunity in the future.
* Used for the Timeline View and Priority Calculation.
*
* <p>The base callsign remains the grouping key for scoring and worked-state
* handling. The exact KST login and its chat category are stored separately
* because reminders and external logger handover refer to the selected
* ChatMember entity.</p>
*/
public class ContestSked {
private String targetCallsign;
private double targetAzimuth; // Required for Antenna-Visuals
private long skedTimeEpoch; // The peak time (e.g., AP)
private String targetChatCallsign;
private ChatCategory targetChatCategory;
private double targetAzimuth;
private long skedTimeEpoch;
private Band band;
// Opportunity potential (0..100). -1 means "unknown".
int opportunityPotentialPercent = -1;
// Status flags to prevent spamming alarms
// Status flags to prevent spamming alarms.
private boolean warning3MinSent = false;
private boolean warningNowSent = false;
public ContestSked(String call, double azimuth, long time, Band b) {
this.targetCallsign = call;
/**
* Backward-compatible constructor.
*/
public ContestSked(String call, double azimuth, long time, Band band) {
this(call, call, null, azimuth, time, band);
}
/**
* Creates a sked for one exact KST login.
*
* @param callRaw base callsign used for scoring and worked states
* @param chatCallsign exact KST login, including an optional dash suffix
* @param chatCategory category in which the selected login is active
* @param azimuth target azimuth
* @param time sked time in epoch milliseconds
* @param band selected amateur-radio band
*/
public ContestSked(String callRaw,
String chatCallsign,
ChatCategory chatCategory,
double azimuth,
long time,
Band band) {
this.targetCallsign = callRaw;
this.targetChatCallsign = chatCallsign;
this.targetChatCategory = chatCategory;
this.targetAzimuth = azimuth;
this.skedTimeEpoch = time;
this.band = b;
this.band = band;
}
/**
@@ -32,15 +65,54 @@ public class ContestSked {
return (skedTimeEpoch - System.currentTimeMillis()) / 1000;
}
// Getters and Setters...
public String getTargetCallsign() { return targetCallsign; }
public double getTargetAzimuth() { return targetAzimuth; }
public long getSkedTimeEpoch() { return skedTimeEpoch; }
public Band getBand() { return band; }
public boolean isWarning3MinSent() { return warning3MinSent; }
public void setWarning3MinSent(boolean b) { this.warning3MinSent = b; }
public boolean isWarningNowSent() { return warningNowSent; }
public void setWarningNowSent(boolean b) { this.warningNowSent = b; }
/**
* Returns the base callsign used for scoring and worked-state grouping.
*/
public String getTargetCallsign() {
return targetCallsign;
}
/**
* Returns the exact KST login selected when the sked was created.
*/
public String getTargetChatCallsign() {
if (targetChatCallsign == null || targetChatCallsign.isBlank()) {
return targetCallsign;
}
return targetChatCallsign;
}
public ChatCategory getTargetChatCategory() {
return targetChatCategory;
}
public double getTargetAzimuth() {
return targetAzimuth;
}
public long getSkedTimeEpoch() {
return skedTimeEpoch;
}
public Band getBand() {
return band;
}
public boolean isWarning3MinSent() {
return warning3MinSent;
}
public void setWarning3MinSent(boolean warning3MinSent) {
this.warning3MinSent = warning3MinSent;
}
public boolean isWarningNowSent() {
return warningNowSent;
}
public void setWarningNowSent(boolean warningNowSent) {
this.warningNowSent = warningNowSent;
}
public int getOpportunityPotentialPercent() {
return opportunityPotentialPercent;
@@ -0,0 +1,73 @@
package kst4contest.test;
import kst4contest.model.ChatPreferences;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.io.TempDir;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import static org.junit.jupiter.api.Assertions.assertFalse;
import static org.junit.jupiter.api.Assertions.assertTrue;
class ChatPreferencesStationMapVisibilityTest {
@TempDir
Path temporaryDirectory;
@Test
void pathAnalysisIsVisibleByDefault() {
ChatPreferences preferences = new ChatPreferences();
assertTrue(preferences.isGUIstationMapPathAnalysisVisible());
}
@Test
void hiddenPathAnalysisStateSurvivesXmlRoundTrip() throws IOException {
Path preferencesFile = temporaryDirectory.resolve("preferences.xml");
ChatPreferences writtenPreferences = new ChatPreferences();
writtenPreferences.setStoreAndRestorePreferencesFileName(
preferencesFile.toString());
writtenPreferences.setGUIstationMapPathAnalysisVisible(false);
writtenPreferences.writePreferencesToXmlFile();
String writtenXml = Files.readString(preferencesFile);
assertTrue(writtenXml.contains(
"<GUIstationMapPathAnalysisVisible>false"
+ "</GUIstationMapPathAnalysisVisible>"));
ChatPreferences restoredPreferences = new ChatPreferences();
restoredPreferences.setStoreAndRestorePreferencesFileName(
preferencesFile.toString());
restoredPreferences.readPreferencesFromXmlFile();
assertFalse(restoredPreferences.isGUIstationMapPathAnalysisVisible());
}
@Test
void legacyXmlWithoutVisibilitySettingKeepsAnalysisDiscoverable()
throws IOException {
Path legacyPreferencesFile =
temporaryDirectory.resolve("legacy-preferences.xml");
Files.writeString(legacyPreferencesFile, """
<?xml version="1.0" encoding="UTF-8"?>
<praktiKST>
<configVersion>4</configVersion>
<guiOptions>
<GUIstationMapStageSceneSizeHW>1000.0;800.0</GUIstationMapStageSceneSizeHW>
</guiOptions>
</praktiKST>
""");
ChatPreferences restoredPreferences = new ChatPreferences();
restoredPreferences.setStoreAndRestorePreferencesFileName(
legacyPreferencesFile.toString());
restoredPreferences.readPreferencesFromXmlFile();
assertTrue(restoredPreferences.isGUIstationMapPathAnalysisVisible());
}
}
@@ -0,0 +1,112 @@
package kst4contest.test;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import javafx.beans.property.SimpleDoubleProperty;
import javafx.beans.property.SimpleStringProperty;
import javafx.collections.FXCollections;
import kst4contest.controller.MessageVariableResolver;
import kst4contest.model.AirPlane;
import kst4contest.model.AirPlaneReflectionInfo;
import kst4contest.model.ChatMember;
import kst4contest.model.ChatPreferences;
class MessageVariableResolverTest {
private ChatPreferences chatPreferences;
private MessageVariableResolver resolver;
@BeforeEach
void setUp() {
chatPreferences = mock(ChatPreferences.class);
when(chatPreferences.getMYQRGFirstCat()).thenReturn(new SimpleStringProperty("144.388.03"));
when(chatPreferences.getMYQRGSecondCat()).thenReturn(new SimpleStringProperty("432.088.00"));
when(chatPreferences.getStn_loginLocatorMainCat()).thenReturn("JO51IJ");
when(chatPreferences.getStn_loginCallSign()).thenReturn("DO5AMF");
when(chatPreferences.getActualQTF()).thenReturn(new SimpleDoubleProperty(135.0));
resolver = new MessageVariableResolver(chatPreferences);
}
@Test
void resolvesAllGlobalVariablesInEveryMessageContext() {
String template = "MYCALL MYQRGSHORT MYQRG SECONDQRG MYLOCATORSHORT MYLOCATOR MYQTF";
assertEquals(
"DO5AMF 144.388 144.388.03 432.088.00 JO51 JO51IJ 135",
resolver.resolveGlobalVariables(template)
);
}
@Test
void shortValuesRemainSafeWhenTheConfiguredValueIsShorterThanExpected() {
when(chatPreferences.getMYQRGFirstCat()).thenReturn(new SimpleStringProperty("144"));
when(chatPreferences.getStn_loginLocatorMainCat()).thenReturn("JO5");
assertEquals("144 JO5", resolver.resolveGlobalVariables("MYQRGSHORT MYLOCATORSHORT"));
}
@Test
void resolvesSelectedStationNameAndTheFirstTwoAirPlanes() {
ChatMember selectedStation = new ChatMember();
selectedStation.setCallSign("DL0TEST");
selectedStation.setName("Test Operator");
AirPlane firstAirPlane = new AirPlane();
firstAirPlane.setPotential(100);
firstAirPlane.setArrivingDurationMinutes(1);
AirPlane secondAirPlane = new AirPlane();
secondAirPlane.setPotential(75);
secondAirPlane.setArrivingDurationMinutes(9);
AirPlaneReflectionInfo reflectionInfo = new AirPlaneReflectionInfo();
reflectionInfo.setRisingAirplanes(FXCollections.observableArrayList(firstAirPlane, secondAirPlane));
selectedStation.setAirPlaneReflectInfo(reflectionInfo);
assertEquals(
"Hi Test Operator, a very big AP in 1 min; Next big AP in 9 min",
resolver.resolveForSelectedStation(
"Hi QRZNAME, FIRSTAP; SECONDAP",
selectedStation
)
);
}
@Test
void usesCallsignWhenTheSelectedStationHasNoName() {
ChatMember selectedStation = new ChatMember();
selectedStation.setCallSign("DL0TEST");
selectedStation.setName(" ");
assertEquals(
"Hi DL0TEST",
resolver.resolveForSelectedStation("Hi QRZNAME", selectedStation)
);
}
@Test
void keepsStationVariablesVisibleWhenNoStationIsSelected() {
assertEquals(
"QRZNAME FIRSTAP SECONDAP",
resolver.resolveForSelectedStation("QRZNAME FIRSTAP SECONDAP", null)
);
}
@Test
void returnsUsefulFallbacksWhenNoAirPlaneIsAvailable() {
ChatMember selectedStation = new ChatMember();
selectedStation.setCallSign("DL0TEST");
assertEquals(
"no ap available ",
resolver.resolveForSelectedStation("FIRSTAP SECONDAP", selectedStation)
);
}
}
File diff suppressed because it is too large Load Diff
@@ -0,0 +1,327 @@
package kst4contest.view;
import javafx.geometry.Insets;
import javafx.geometry.Pos;
import javafx.scene.control.Hyperlink;
import javafx.scene.control.Label;
import javafx.scene.control.TableCell;
import javafx.scene.control.Tooltip;
import javafx.scene.layout.HBox;
import javafx.scene.layout.Region;
import javafx.scene.shape.Rectangle;
import javafx.util.Duration;
import java.net.URI;
import java.util.Locale;
import java.util.Objects;
import java.util.function.Consumer;
import java.util.function.Predicate;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
/**
* Displays a single-line message text in a TableView.
*
* <p>The cell provides two functions that JavaFX's default text cell cannot
* combine:
* <ul>
* <li>a tooltip containing the complete text, but only while the visible
* cell is too narrow for that text;</li>
* <li>clickable HTTP, HTTPS and www links inside otherwise normal text.</li>
* </ul>
*
* <p>The row type is generic because the same implementation is used by the
* ChatMessage tables and the DX-cluster table.</p>
*
* @param <S> row type of the surrounding TableView
*/
public final class MessageTextTableCell<S> extends TableCell<S, String> {
private static final Pattern WEB_LINK_PATTERN = Pattern.compile(
"(?i)\\b(?:https?://|www\\.)[^\\s<>\"']+"
);
private static final String TRAILING_LINK_PUNCTUATION = ".,;:!?)]}";
private final Consumer<String> linkOpener;
private final Predicate<String> highlightedTextPredicate;
private final String normalStyleClass;
private final String highlightedStyleClass;
private final HBox contentBox = new HBox(0);
private final Rectangle contentClip = new Rectangle();
private final Tooltip fullTextTooltip = new Tooltip();
private String displayedText = "";
private boolean fullTextTooltipInstalled = false;
/**
* Creates a normal message cell without additional text highlighting.
*
* @param linkOpener callback which opens a validated HTTP or HTTPS URL
*/
public MessageTextTableCell(Consumer<String> linkOpener) {
this(linkOpener, text -> false, null, null);
}
/**
* Creates a message cell with optional CSS highlighting.
*
* <p>KST4Contest uses this variant for public messages which contain the
* operator's own callsign. Only the supplied CSS classes are added or
* removed. The standard {@code table-cell} class and all other JavaFX
* state remain untouched.</p>
*
* @param linkOpener callback which opens a validated URL
* @param highlightedTextPredicate identifies highlighted messages
* @param normalStyleClass CSS class for normal messages, may be null
* @param highlightedStyleClass CSS class for highlighted messages, may be null
*/
public MessageTextTableCell(
Consumer<String> linkOpener,
Predicate<String> highlightedTextPredicate,
String normalStyleClass,
String highlightedStyleClass
) {
this.linkOpener = Objects.requireNonNull(linkOpener, "linkOpener");
this.highlightedTextPredicate = highlightedTextPredicate == null
? text -> false
: highlightedTextPredicate;
this.normalStyleClass = normalStyleClass;
this.highlightedStyleClass = highlightedStyleClass;
contentBox.setAlignment(Pos.CENTER_LEFT);
contentBox.setFillHeight(false);
contentBox.setClip(contentClip);
fullTextTooltip.setWrapText(true);
fullTextTooltip.setMaxWidth(800);
fullTextTooltip.setShowDelay(Duration.millis(250));
fullTextTooltip.setShowDuration(Duration.seconds(30));
setContentDisplay(javafx.scene.control.ContentDisplay.GRAPHIC_ONLY);
}
@Override
protected void updateItem(String item, boolean empty) {
super.updateItem(item, empty);
removeOptionalStyleClasses();
contentBox.getChildren().clear();
if (empty || item == null || item.isEmpty()) {
displayedText = "";
fullTextTooltip.setText("");
setText(null);
setGraphic(null);
setClippedTooltipActive(false);
return;
}
displayedText = item;
fullTextTooltip.setText(item);
applyOptionalStyleClass(item);
buildContent(item);
setText(null);
setGraphic(contentBox);
updateClipAndTooltip();
}
@Override
protected void layoutChildren() {
super.layoutChildren();
updateClipAndTooltip();
}
/**
* Splits the displayed text into ordinary labels and clickable links.
*/
private void buildContent(String text) {
Matcher matcher = WEB_LINK_PATTERN.matcher(text);
int nextPlainTextStart = 0;
while (matcher.find()) {
String rawMatch = matcher.group();
String linkText = removeTrailingPunctuation(rawMatch);
if (linkText.isEmpty()) {
continue;
}
appendPlainText(text.substring(nextPlainTextStart, matcher.start()));
appendLink(linkText);
/*
* Punctuation removed from the URL remains ordinary message text.
* Starting here ensures it is included by the next substring.
*/
nextPlainTextStart = matcher.start() + linkText.length();
}
appendPlainText(text.substring(nextPlainTextStart));
}
private void appendPlainText(String text) {
if (text == null || text.isEmpty()) {
return;
}
Label textFragment = new Label(text);
textFragment.setPadding(Insets.EMPTY);
textFragment.setMinWidth(Region.USE_PREF_SIZE);
textFragment.setMaxWidth(Region.USE_PREF_SIZE);
textFragment.setMouseTransparent(true);
textFragment.textFillProperty().bind(textFillProperty());
textFragment.getStyleClass().add("message-text-fragment");
contentBox.getChildren().add(textFragment);
}
private void appendLink(String linkText) {
Hyperlink hyperlink = new Hyperlink(linkText);
hyperlink.setPadding(Insets.EMPTY);
hyperlink.setMinWidth(Region.USE_PREF_SIZE);
hyperlink.setMaxWidth(Region.USE_PREF_SIZE);
hyperlink.setFocusTraversable(false);
hyperlink.getStyleClass().add("message-table-link");
hyperlink.setOnAction(event -> {
openLink(linkText);
event.consume();
});
contentBox.getChildren().add(hyperlink);
}
/**
* Opens only HTTP and HTTPS targets. A visible www address receives an
* HTTPS scheme before it is passed to the application.
*/
private void openLink(String linkText) {
try {
String normalizedLink = linkText.toLowerCase(Locale.ROOT).startsWith("www.")
? "https://" + linkText
: linkText;
URI uri = URI.create(normalizedLink);
String scheme = uri.getScheme();
if (scheme == null
|| (!scheme.equalsIgnoreCase("http")
&& !scheme.equalsIgnoreCase("https"))) {
return;
}
linkOpener.accept(uri.toASCIIString());
} catch (RuntimeException exception) {
System.out.println(
"[MessageTextTableCell] Cannot open malformed link: "
+ linkText
+ " / "
+ exception.getMessage()
);
}
}
/**
* Removes punctuation which commonly follows a link in normal prose.
*/
private String removeTrailingPunctuation(String rawLink) {
String result = rawLink;
while (!result.isEmpty()
&& TRAILING_LINK_PUNCTUATION.indexOf(
result.charAt(result.length() - 1)
) >= 0) {
result = result.substring(0, result.length() - 1);
}
return result;
}
/**
* Clips the one-line content and installs the full-text tooltip only if
* the rendered nodes are wider than the usable cell area.
*/
private void updateClipAndTooltip() {
if (displayedText.isEmpty() || getGraphic() == null) {
setClippedTooltipActive(false);
return;
}
double availableWidth = Math.max(
0,
getWidth() - snappedLeftInset() - snappedRightInset()
);
double availableHeight = Math.max(
0,
getHeight() - snappedTopInset() - snappedBottomInset()
);
contentClip.setWidth(availableWidth);
contentClip.setHeight(availableHeight);
boolean textIsClipped = contentBox.prefWidth(-1) > availableWidth + 1;
setClippedTooltipActive(textIsClipped);
}
/**
* Installs the tooltip on the actual graphic node below the mouse pointer.
*
* <p>Installing it on the TableCell itself is not reliable when the cell
* displays an HBox containing labels and hyperlinks. The graphic node is
* the effective mouse target. Installation is tracked explicitly so
* repeated layout passes neither add duplicate handlers nor leave a
* tooltip attached to a reused empty cell.</p>
*/
private void setClippedTooltipActive(boolean active) {
/*
* The tooltip is handled exclusively by the graphic node. Keeping a
* second tooltip on the TableCell would allow two competing tooltip
* targets for the same visible content.
*/
setTooltip(null);
if (active == fullTextTooltipInstalled) {
return;
}
if (active) {
Tooltip.install(contentBox, fullTextTooltip);
} else {
fullTextTooltip.hide();
Tooltip.uninstall(contentBox, fullTextTooltip);
}
fullTextTooltipInstalled = active;
}
private void applyOptionalStyleClass(String item) {
boolean highlighted;
try {
highlighted = highlightedTextPredicate.test(item);
} catch (RuntimeException exception) {
highlighted = false;
}
String styleClass = highlighted
? highlightedStyleClass
: normalStyleClass;
if (styleClass != null
&& !styleClass.isBlank()
&& !getStyleClass().contains(styleClass)) {
getStyleClass().add(styleClass);
}
}
private void removeOptionalStyleClasses() {
if (normalStyleClass != null) {
getStyleClass().remove(normalStyleClass);
}
if (highlightedStyleClass != null) {
getStyleClass().remove(highlightedStyleClass);
}
}
}
@@ -208,7 +208,12 @@ public class TimelineView extends Pane {
diamond.setFill(colorForPotential(sked.getOpportunityPotentialPercent()));
String baseToolTipFallBack = sked.getTargetCallsign() + " (" + sked.getBand() + ")\nAz: " + sked.getTargetAzimuth();
String baseToolTipFallBack =
sked.getTargetChatCallsign()
+ " ("
+ sked.getBand()
+ ")\nAz: "
+ sked.getTargetAzimuth();
if (skedTooltipExtraTextProvider != null) {
String extra = skedTooltipExtraTextProvider.apply(sked);
@@ -220,7 +225,9 @@ public class TimelineView extends Pane {
Tooltip t = new Tooltip(baseToolTipFallBack);
Tooltip.install(diamond, t);
Label lbl = new Label("SKED: " + sked.getTargetCallsign());
Label lbl = new Label(
"SKED: " + sked.getTargetChatCallsign()
);
// lbl.setFont(new Font(9));
// lbl.setTextFill(Color.WHITE);
lbl.setLayoutY(14);
@@ -1,6 +1,7 @@
package kst4contest.view.map;
import kst4contest.locatorUtils.Location;
import kst4contest.logic.BandOpportunityResolver;
import kst4contest.model.AirPlaneReflectionInfo;
import kst4contest.model.Band;
import kst4contest.model.ChatMember;
@@ -14,7 +15,6 @@ import java.util.LinkedHashMap;
import java.util.List;
import java.util.Locale;
import java.util.Map;
import java.util.regex.Pattern;
/**
* Builds immutable map snapshots from the currently visible chat members.
@@ -24,8 +24,6 @@ import java.util.regex.Pattern;
*/
public final class MapCallsignRawSnapshotBuilder {
private static final Pattern TOKEN_SPLIT_PATTERN = Pattern.compile("[^A-Z0-9]+");
public List<MapCallsignRawSnapshot> buildSnapshots(Collection<ChatMember> visibleChatMembers,
ChatMember selectedChatMember,
EnumSet<Band> selectedBands) {
@@ -73,10 +71,21 @@ public final class MapCallsignRawSnapshotBuilder {
Location location = new Location(locator6);
LinkedHashMap<String, String> frequenciesByBand = collectLastKnownFrequenciesByBand(variants);
EnumSet<Band> sureBands = collectSureBands(variants, frequenciesByBand);
String bandSummary = buildBandSummary(sureBands);
boolean offersSelectedBand = hasAnySelectedBand(sureBands, selectedBands);
long nowEpochMs = System.currentTimeMillis();
BandOpportunityResolver.Resolution bandResolution =
BandOpportunityResolver.resolve(variants, nowEpochMs);
EnumSet<Band> availableBands = bandResolution.getAvailableBands();
LinkedHashMap<String, String> frequenciesByBand = collectLastKnownFrequenciesByBand(
variants,
availableBands,
nowEpochMs
);
String bandSummary = buildBandSummary(availableBands);
boolean offersSelectedBand = !bandResolution
.getUnworkedEnabledBands(selectedBands)
.isEmpty();
boolean warningToMyDirection = variants.stream().anyMatch(ChatMember::isInAngleAndRange);
boolean worked = variants.stream().anyMatch(this::isWorkedAtAnyBand);
@@ -152,7 +161,11 @@ public final class MapCallsignRawSnapshotBuilder {
.orElse("");
}
private LinkedHashMap<String, String> collectLastKnownFrequenciesByBand(List<ChatMember> variants) {
private LinkedHashMap<String, String> collectLastKnownFrequenciesByBand(
List<ChatMember> variants,
EnumSet<Band> availableBands,
long nowEpochMs
) {
Map<Band, FrequencyCandidate> latestByBand = new EnumMap<>(Band.class);
@@ -161,16 +174,29 @@ public final class MapCallsignRawSnapshotBuilder {
continue;
}
for (Map.Entry<Band, ChatMember.ActiveFrequencyInfo> bandEntry : variant.getKnownActiveBands().entrySet()) {
for (Map.Entry<Band, ChatMember.ActiveFrequencyInfo> bandEntry
: variant.getKnownActiveBands().entrySet()) {
Band band = bandEntry.getKey();
ChatMember.ActiveFrequencyInfo activeFrequencyInfo = bandEntry.getValue();
if (band == null || activeFrequencyInfo == null) {
if (band == null
|| activeFrequencyInfo == null
|| availableBands == null
|| !availableBands.contains(band)) {
continue;
}
long ageMs = nowEpochMs - activeFrequencyInfo.timestampEpoch;
if (ageMs < 0L
|| ageMs > BandOpportunityResolver.RECENT_DYNAMIC_EVIDENCE_MAX_AGE_MS) {
continue;
}
FrequencyCandidate previous = latestByBand.get(band);
if (previous == null || activeFrequencyInfo.timestampEpoch > previous.timestampEpochMs()) {
if (previous == null
|| activeFrequencyInfo.timestampEpoch > previous.timestampEpochMs()) {
latestByBand.put(band, new FrequencyCandidate(
band,
formatFrequency(activeFrequencyInfo.frequency),
@@ -178,152 +204,31 @@ public final class MapCallsignRawSnapshotBuilder {
));
}
}
addFallbackCurrentFrequencyIfUseful(variant, latestByBand);
}
LinkedHashMap<String, String> ordered = new LinkedHashMap<>();
latestByBand.entrySet().stream()
.sorted(Map.Entry.comparingByKey())
.forEach(entry -> ordered.put(toBandDisplayLabel(entry.getKey()), entry.getValue().formattedFrequency()));
.forEach(entry -> ordered.put(
toBandDisplayLabel(entry.getKey()),
entry.getValue().formattedFrequency()
));
return ordered;
}
private EnumSet<Band> collectSureBands(List<ChatMember> variants,
LinkedHashMap<String, String> frequenciesByBand) {
EnumSet<Band> sureBands = EnumSet.noneOf(Band.class);
if (frequenciesByBand != null) {
for (String label : frequenciesByBand.keySet()) {
Band mappedBand = bandFromDisplayLabel(label);
if (mappedBand != null) {
sureBands.add(mappedBand);
}
}
}
for (ChatMember variant : variants) {
if (variant == null || variant.getName() == null || variant.getName().isBlank()) {
continue;
}
sureBands.addAll(detectBandsFromStationName(variant.getName()));
}
return sureBands;
}
private EnumSet<Band> detectBandsFromStationName(String stationName) {
EnumSet<Band> detectedBands = EnumSet.noneOf(Band.class);
if (stationName == null || stationName.isBlank()) {
return detectedBands;
}
String normalized = stationName.toUpperCase(Locale.ROOT);
String[] tokens = TOKEN_SPLIT_PATTERN.split(normalized);
for (String token : tokens) {
if (token == null || token.isBlank()) {
continue;
}
switch (token) {
case "2", "2M", "144", "144MHZ" -> detectedBands.add(Band.B_144);
case "70", "70CM", "432", "432MHZ" -> detectedBands.add(Band.B_432);
case "23", "23CM", "1296", "1296MHZ" -> detectedBands.add(Band.B_1296);
case "13", "13CM", "2300", "2320", "2320MHZ" -> detectedBands.add(Band.B_2320);
case "9", "9CM", "3400", "3400MHZ" -> detectedBands.add(Band.B_3400);
case "6", "6CM", "5600", "5760", "5760MHZ" -> detectedBands.add(Band.B_5760);
case "3", "3CM", "10G", "10GHZ", "10368", "10368MHZ" -> detectedBands.add(Band.B_10G);
case "24G", "24GHZ", "24048", "24048MHZ" -> detectedBands.add(Band.B_24G);
default -> {
}
}
}
return detectedBands;
}
private String buildBandSummary(EnumSet<Band> sureBands) {
if (sureBands == null || sureBands.isEmpty()) {
private String buildBandSummary(EnumSet<Band> availableBands) {
if (availableBands == null || availableBands.isEmpty()) {
return "";
}
List<String> labels = sureBands.stream()
List<String> labels = availableBands.stream()
.sorted()
.map(this::toBandDisplayLabel)
.toList();
return String.join(", ", labels);
}
private boolean hasAnySelectedBand(EnumSet<Band> sureBands, EnumSet<Band> selectedBands) {
if (sureBands == null || sureBands.isEmpty() || selectedBands == null || selectedBands.isEmpty()) {
return false;
}
for (Band band : selectedBands) {
if (sureBands.contains(band)) {
return true;
}
}
return false;
}
private Band bandFromDisplayLabel(String label) {
if (label == null || label.isBlank()) {
return null;
}
return switch (label) {
case "144" -> Band.B_144;
case "432" -> Band.B_432;
case "1296" -> Band.B_1296;
case "2320" -> Band.B_2320;
case "3400" -> Band.B_3400;
case "5760" -> Band.B_5760;
case "10368" -> Band.B_10G;
case "24048" -> Band.B_24G;
default -> null;
};
}
/**
* Fallback for stations where the current displayed QRG exists but the
* knownActiveBands history has not yet been filled.
*
* This parsing is intentionally tolerant so strings like "144.300 MHz"
* can still be used.
*/
private void addFallbackCurrentFrequencyIfUseful(ChatMember variant, Map<Band, FrequencyCandidate> latestByBand) {
if (variant == null || variant.getFrequency() == null || variant.getFrequency().getValue() == null) {
return;
}
String rawFrequency = variant.getFrequency().getValue().trim();
if (rawFrequency.isBlank()) {
return;
}
double parsedFrequencyMHz = PathGeometryUtils.tryParseFrequencyMHz(rawFrequency);
if (!Double.isFinite(parsedFrequencyMHz) || parsedFrequencyMHz <= 0.0) {
return;
}
Band detectedBand = Band.fromFrequency(parsedFrequencyMHz);
if (detectedBand == null) {
return;
}
FrequencyCandidate previous = latestByBand.get(detectedBand);
if (previous != null && previous.timestampEpochMs() >= variant.getActivityTimeLastInEpoch()) {
return;
}
latestByBand.put(detectedBand, new FrequencyCandidate(
detectedBand,
formatFrequency(parsedFrequencyMHz),
variant.getActivityTimeLastInEpoch()
));
}
private boolean isWorkedAtAnyBand(ChatMember member) {
return member.isWorked()
|| member.isWorked50()
@@ -370,6 +275,8 @@ public final class MapCallsignRawSnapshotBuilder {
private String toBandDisplayLabel(Band band) {
return switch (band) {
case B_50 -> "50";
case B_70 -> "70";
case B_144 -> "144";
case B_432 -> "432";
case B_1296 -> "1296";
@@ -240,6 +240,36 @@ public record PathAnalysisResult(
);
}
/**
* Creates a placeholder when automatic band resolution has no usable result.
*/
public static PathAnalysisResult waitingForUsableBand(String fromLocator6,
String toLocator6,
String toCallsignRaw) {
return new PathAnalysisResult(
"Waiting",
fromLocator6,
toLocator6,
toCallsignRaw,
Double.NaN,
Double.NaN,
Double.NaN,
Double.NaN,
Double.NaN,
false,
false,
Double.NaN,
Double.NaN,
Double.NaN,
Double.NaN,
Double.NaN,
-1,
"No usable automatic band is available. "
+ "Check own enabled bands and the station's NOT-QRV tags.",
List.of()
);
}
/**
* Creates a finished result without a usable terrain profile.
*
@@ -343,6 +343,8 @@ public final class StationMapBridge {
+ "|"
+ String.format(Locale.US, "%.3f", analysisFrequencyMHz)
+ "|"
+ selectedSnapshot.bandSummary()
+ "|"
+ String.format(Locale.US, "%.1f", preferences.getStn_pathAnalysisOwnAntennaHeightMeters())
+ "|"
+ String.format(Locale.US, "%.1f", preferences.getStn_pathAnalysisDefaultTargetAntennaHeightMeters())
@@ -28,6 +28,8 @@ import javafx.scene.control.ScrollPane;
import javafx.scene.layout.Priority;
import javafx.scene.layout.Region;
import javafx.scene.layout.ColumnConstraints;
import javafx.geometry.Pos;
import javafx.scene.layout.HBox;
/**
* Standalone station map window.
@@ -49,6 +51,9 @@ public final class StationMapView {
*/
private static final boolean MAP_DEBUG_LOGGING = false;
private static final double MINIMUM_HEIGHT_WITH_PATH_ANALYSIS = 650.0;
private static final double MINIMUM_HEIGHT_WITHOUT_PATH_ANALYSIS = 420.0;
private final PathProfileChart detailPathProfileChart = new PathProfileChart();
private final Label detailPathModeValue = new Label("-");
@@ -76,6 +81,12 @@ public final class StationMapView {
private VBox detailPane;
private final Label statusLabel = new Label("Station map not initialized yet.");
private final Label pathAnalysisHiddenHintLabel = new Label("Path analysis is hidden.");
private final Button pathAnalysisVisibilityButton = new Button();
private final Tooltip pathAnalysisVisibilityTooltip = new Tooltip();
private final Label detailCallsignValue = new Label("-");
private final Label detailLocatorValue = new Label("-");
private final Label detailQrbValue = new Label("-");
@@ -138,8 +149,12 @@ public final class StationMapView {
private PathAnalysisResult lastPathAnalysisResult = PathAnalysisResult.waitingForSelection("");
private VBox mapAndProfilePane;
private VBox profileSection;
private VBox pathAnalysisSection;
private ScrollPane detailScrollPane;
private final Label detailPathLosValue = new Label("-");
private final Label detailPathWorstClearanceValue = new Label("-");
@@ -287,6 +302,14 @@ public final class StationMapView {
}
});
pathAnalysisVisibilityButton.setMinWidth(Region.USE_PREF_SIZE);
pathAnalysisVisibilityButton.setTooltip(pathAnalysisVisibilityTooltip);
pathAnalysisVisibilityButton.setOnAction(event ->
setPathAnalysisVisible(!profileSection.isVisible(), true));
pathAnalysisHiddenHintLabel.setMinWidth(Region.USE_PREF_SIZE);
pathAnalysisHiddenHintLabel.setStyle("-fx-font-style: italic; -fx-opacity: 0.85;");
webView.setFocusTraversable(true);
webView.setPickOnBounds(true);
@@ -323,7 +346,8 @@ public final class StationMapView {
webView.widthProperty().addListener((obs, oldValue, newValue) -> requestMapInvalidateSize());
webView.heightProperty().addListener((obs, oldValue, newValue) -> requestMapInvalidateSize());
VBox profileSection = createProfileSection();
profileSection = createProfileSection();
mapAndProfilePane = new VBox(6, webView, profileSection);
mapAndProfilePane.setPadding(new Insets(0));
@@ -349,10 +373,9 @@ public final class StationMapView {
mapAndProfilePane.widthProperty().subtract(20)
);
detailPane = new VBox(10,
createSelectedStationSection(),
createPathAnalysisSection()
);
pathAnalysisSection = createPathAnalysisSection();
detailPane = new VBox(10, createSelectedStationSection(), pathAnalysisSection);
detailPane.setPadding(new Insets(10));
detailPane.setMinWidth(0);
@@ -364,8 +387,14 @@ public final class StationMapView {
detailScrollPane.setFitToWidth(true);
detailScrollPane.setHbarPolicy(ScrollPane.ScrollBarPolicy.NEVER);
detailScrollPane.setVbarPolicy(ScrollPane.ScrollBarPolicy.AS_NEEDED);
detailScrollPane.setMinWidth(300);
/*
* Allow the details pane to be reduced far enough to leave more room for the
* map. At its minimum width, a callsign with up to ten characters remains
* readable.
*/
detailScrollPane.setMinWidth(210);
detailScrollPane.setPrefWidth(350);
detailScrollPane.setMaxWidth(Double.MAX_VALUE);
detailScrollPane.setFitToWidth(true);
@@ -378,8 +407,7 @@ public final class StationMapView {
SplitPane.setResizableWithParent(detailScrollPane, true);
rootPane = new BorderPane();
rootPane.setTop(statusLabel);
BorderPane.setMargin(statusLabel, new Insets(8));
rootPane.setTop(createMapHeader());
rootPane.setCenter(mainSplitPane);
double[] size = chatPreferences.getGUIstationMapStageSceneSizeHW();
@@ -390,7 +418,12 @@ public final class StationMapView {
scene = new Scene(rootPane, initialWidth, initialHeight);
stage.setMinWidth(900);
stage.setMinHeight(650);
stage.setMinHeight(resolveMinimumStationMapHeight(
chatPreferences.isGUIstationMapPathAnalysisVisible()));
stage.setScene(scene);
setPathAnalysisVisible(chatPreferences.isGUIstationMapPathAnalysisVisible(), false);
applyThemeFromPreferences();
stage.setScene(scene);
applyThemeFromPreferences();
@@ -446,6 +479,91 @@ public final class StationMapView {
}
/**
* Creates an always-visible header for the map status and analysis controls.
*
* Keeping the control outside the sections that it hides is important: users
* 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);
HBox header = new HBox(
10,
statusLabel,
pathAnalysisHiddenHintLabel,
pathAnalysisVisibilityButton
);
header.setAlignment(Pos.CENTER_LEFT);
header.setPadding(new Insets(8));
HBox.setHgrow(statusLabel, Priority.ALWAYS);
return header;
}
/**
* Shows or hides both parts of the path analysis as one logical feature.
*
* Both visible and managed must be changed. A node that is merely invisible
* would still reserve layout space and the map would not grow into that area.
* The current analysis result remains attached to the controls and is
* immediately available again when the user restores the sections.
*
* @param visible true to show the profile and detailed analysis
* @param persist true when the change was explicitly requested by the user
*/
private void setPathAnalysisVisible(boolean visible, boolean persist) {
profileSection.setVisible(visible);
profileSection.setManaged(visible);
pathAnalysisSection.setVisible(visible);
pathAnalysisSection.setManaged(visible);
pathAnalysisHiddenHintLabel.setVisible(!visible);
pathAnalysisHiddenHintLabel.setManaged(!visible);
pathAnalysisVisibilityButton.setText(
visible ? "Hide path analysis" : "Show path analysis");
pathAnalysisVisibilityButton.setAccessibleText(
visible ? "Hide path analysis" : "Show path analysis");
pathAnalysisVisibilityButton.setStyle(
visible ? "" : "-fx-font-weight: bold;");
pathAnalysisVisibilityTooltip.setText(visible
? "Hide the path profile and detailed path analysis. You can show them again at any time."
: "Show the path profile and detailed path analysis.");
pathAnalysisVisibilityButton.setAccessibleHelp(
pathAnalysisVisibilityTooltip.getText());
if (!visible) {
/*
* Do not leave a profile hover marker on the map after its chart was
* hidden.
*/
showProfileHoverPointOnMap(null);
}
stage.setMinHeight(resolveMinimumStationMapHeight(visible));
if (persist) {
chatPreferences.setGUIstationMapPathAnalysisVisible(visible);
}
if (rootPane != null) {
rootPane.requestLayout();
Platform.runLater(this::requestMapInvalidateSize);
}
}
private double resolveMinimumStationMapHeight(boolean pathAnalysisVisible) {
return pathAnalysisVisible
? MINIMUM_HEIGHT_WITH_PATH_ANALYSIS
: MINIMUM_HEIGHT_WITHOUT_PATH_ANALYSIS;
}
private VBox createSelectedStationSection() {
GridPane detailGrid = new GridPane();
detailGrid.setHgap(8);
@@ -494,13 +612,18 @@ public final class StationMapView {
gridPane.getColumnConstraints().clear();
ColumnConstraints labelColumn = new ColumnConstraints();
labelColumn.setMinWidth(105);
labelColumn.setMinWidth(70);
labelColumn.setPrefWidth(115);
labelColumn.setMaxWidth(130);
labelColumn.setHgrow(Priority.NEVER);
ColumnConstraints valueColumn = new ColumnConstraints();
valueColumn.setMinWidth(180);
/*
* Reserve enough space for a callsign with up to ten characters, while still
* allowing the details pane to become considerably narrower.
*/
valueColumn.setMinWidth(85);
valueColumn.setHgrow(Priority.ALWAYS);
gridPane.getColumnConstraints().addAll(labelColumn, valueColumn);
@@ -1530,8 +1653,11 @@ public final class StationMapView {
return 768.0;
}
double minimumHeight = resolveMinimumStationMapHeight(
chatPreferences.isGUIstationMapPathAnalysisVisible());
// Avoid restoring very large old test sizes after the layout changed.
if (storedSize[1] < 650.0 || storedSize[1] > 1100.0) {
if (storedSize[1] < minimumHeight || storedSize[1] > 1100.0) {
return 768.0;
}
+2
View File
@@ -10,6 +10,8 @@ module praktiKST {
requires java.net.http;
requires java.desktop;
requires jdk.crypto.ec;
requires org.junit.jupiter.api;
requires org.mockito;
exports kst4contest.controller.interfaces;
exports kst4contest.controller;
exports kst4contest.locatorUtils;
@@ -198,4 +198,20 @@
.table-cell-50PercentAP {
-fx-text-fill: #fa9f66;
-fx-font-weight: bold;
}
/*
* Clickable web links inside message-table cells.
* Text fragments keep the current table-cell color; links remain visible.
*/
.message-table-link {
-fx-padding: 0;
-fx-border-color: transparent;
-fx-underline: true;
-fx-text-fill: #005eb8;
}
.message-table-link:visited {
-fx-text-fill: #6b3fa0;
}
@@ -240,4 +240,19 @@
.table-cell-50PercentAP {
-fx-text-fill: #fa9f66;
-fx-font-weight: bold;
}
/*
* Clickable web links inside message-table cells.
* Brighter colors preserve contrast on the dark table background.
*/
.message-table-link {
-fx-padding: 0;
-fx-border-color: transparent;
-fx-underline: true;
-fx-text-fill: #73b7ff;
}
.message-table-link:visited {
-fx-text-fill: #c59cff;
}
@@ -0,0 +1,120 @@
package kst4contest.test;
import kst4contest.logic.BandOpportunityResolver;
import kst4contest.model.Band;
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.assertFalse;
import static org.junit.jupiter.api.Assertions.assertTrue;
class BandOpportunityResolverTest {
@Test
void resolvesCommonShorthandBandsFromStationName() {
EnumSet<Band> bands = BandOpportunityResolver.detectBandsFromStationName(
"Peter QRV 2-70-23/13/9/6/3"
);
assertEquals(
EnumSet.of(
Band.B_144,
Band.B_432,
Band.B_1296,
Band.B_2320,
Band.B_3400,
Band.B_5760,
Band.B_10G
),
bands
);
}
@Test
void doesNotMistakeOnePointTwoCentimetersForTwoMeters() {
EnumSet<Band> bands = BandOpportunityResolver.detectBandsFromStationName(
"David 23/3/1.2"
);
assertEquals(EnumSet.of(Band.B_1296, Band.B_10G, Band.B_24G), bands);
assertFalse(bands.contains(Band.B_144));
}
@Test
void keepsOnlyRecentDynamicBandEvidence() {
long now = 1_000_000L;
ChatMember station = new ChatMember();
station.addKnownFrequency(Band.B_144, 144.210);
station.addKnownFrequency(Band.B_432, 432.210);
station.getKnownActiveBands().get(Band.B_144).timestampEpoch = now - 5_000L;
station.getKnownActiveBands().get(Band.B_432).timestampEpoch =
now - BandOpportunityResolver.RECENT_DYNAMIC_EVIDENCE_MAX_AGE_MS - 1L;
BandOpportunityResolver.Resolution resolution =
BandOpportunityResolver.resolve(List.of(station), now);
assertEquals(EnumSet.of(Band.B_144), resolution.getOfferedBands());
}
@Test
void notQrvOverridesNameAndFrequencyEvidenceAcrossVariants() {
long now = 1_000_000L;
ChatMember categoryTwo = new ChatMember();
categoryTwo.setName("QRV 2m 70cm");
categoryTwo.addKnownFrequency(Band.B_432, 432.210);
categoryTwo.getKnownActiveBands().get(Band.B_432).timestampEpoch = now - 1_000L;
ChatMember categoryThree = new ChatMember();
categoryThree.setQrv432(false);
BandOpportunityResolver.Resolution resolution =
BandOpportunityResolver.resolve(List.of(categoryTwo, categoryThree), now);
assertTrue(resolution.getOfferedBands().contains(Band.B_432));
assertFalse(resolution.getAvailableBands().contains(Band.B_432));
assertTrue(resolution.getAvailableBands().contains(Band.B_144));
}
@Test
void detectsFourAndSixMetersWithoutStealingCmShorthandBands() {
EnumSet<Band> bands = BandOpportunityResolver.detectBandsFromStationName(
"QRV 50 70cm 6M 4M"
);
assertEquals(
EnumSet.of(Band.B_50, Band.B_432, Band.B_70),
bands
);
}
@Test
void bareSeventyAndBareSixStillMeanCentimeterBands() {
EnumSet<Band> bands = BandOpportunityResolver.detectBandsFromStationName(
"QRV 70 6"
);
assertEquals(EnumSet.of(Band.B_432, Band.B_5760), bands);
assertFalse(bands.contains(Band.B_70));
assertFalse(bands.contains(Band.B_50));
}
@Test
void opportunityRequiresAvailableEnabledAndUnworkedBand() {
ChatMember station = new ChatMember();
station.setName("2m 70cm");
station.setWorked144(true);
BandOpportunityResolver.Resolution resolution =
BandOpportunityResolver.resolve(List.of(station), System.currentTimeMillis());
assertEquals(
EnumSet.of(Band.B_432),
resolution.getUnworkedEnabledBands(EnumSet.of(Band.B_144, Band.B_432))
);
}
}
@@ -45,6 +45,38 @@ class MapCallsignRawSnapshotBuilderTest {
assertFalse(snapshots.get(0).offersSelectedBand());
}
@Test
void notQrvOverridesNameDerivedMapOpportunity() {
ChatMember station = buildStation("DL1ABC", "QRV 2m 70cm", "JN58TD", 1_000L);
station.setQrv432(false);
MapCallsignRawSnapshotBuilder builder = new MapCallsignRawSnapshotBuilder();
MapCallsignRawSnapshot snapshot = builder.buildSnapshots(
List.of(station),
null,
EnumSet.of(Band.B_432)
).get(0);
assertFalse(snapshot.offersSelectedBand());
assertFalse(snapshot.bandSummary().contains("432"));
}
@Test
void workedBandIsShownAsInformationButNotAsUpgradeOpportunity() {
ChatMember station = buildStation("DL1ABC", "QRV 2m", "JN58TD", 1_000L);
station.setWorked144(true);
MapCallsignRawSnapshotBuilder builder = new MapCallsignRawSnapshotBuilder();
MapCallsignRawSnapshot snapshot = builder.buildSnapshots(
List.of(station),
null,
EnumSet.of(Band.B_144)
).get(0);
assertTrue(snapshot.bandSummary().contains("144"));
assertFalse(snapshot.offersSelectedBand());
}
private ChatMember buildStation(String callSign, String name, String locator, long activityEpoch) {
ChatMember chatMember = new ChatMember();
chatMember.setCallSign(callSign);
+13 -1
View File
@@ -2370,4 +2370,16 @@ DO5SA;unknown;unknown;StringProperty [value: null]; wkd true; wkd144 true; wkd43
9A2HM;unknown;unknown;StringProperty [value: null]; wkd true; wkd144 false; wkd432false; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; null
9A2HM;null;null;StringProperty [value: null]; wkd true; wkd144 false; wkd432true; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; null
9A2HM;null;null;StringProperty [value: null]; wkd true; wkd144 false; wkd432false; wkd1240false; wkd2300true; wkd3400false; wkd5600false; wkd10Gfalse ; null
OV3T;Thomas;JO46CM;StringProperty [value: null]; wkd true; wkd144 true; wkd432false; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
OV3T;Thomas;JO46CM;StringProperty [value: null]; wkd true; wkd144 true; wkd432false; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
OZ1ALS;144307;JO44XX;StringProperty [value: 144.307]; wkd true; wkd144 true; wkd432false; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
OZ1FDH;Claus;JO55QX;StringProperty [value: null]; wkd true; wkd144 true; wkd432false; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
OZ2AR;FRS Club;JO65BT;StringProperty [value: 144.243]; wkd true; wkd144 true; wkd432false; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
SM7NCL;Chris;JO66JI;StringProperty [value: 144.255]; wkd true; wkd144 true; wkd432false; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
OZ1DLD/P;Bent;JO45SK;StringProperty [value: 144.285]; wkd true; wkd144 true; wkd432false; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
SM6VTZ;Chris 2/70/23/3;JO58UJ;StringProperty [value: 144.135]; wkd true; wkd144 true; wkd432false; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
OZ7KJ;Skive Club;JO46ML;StringProperty [value: 144.225]; wkd true; wkd144 true; wkd432false; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
OV3T;Thomas;JO46CM;StringProperty [value: null]; wkd true; wkd144 true; wkd432false; wkd1240false; wkd2300false; wkd3400false; wkd5600false; wkd10Gfalse ; 2: 144/432 MHz
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
+10 -8
View File
@@ -97,15 +97,17 @@ function rewriteManualLinks(content, lang) {
return `[${label}](/manual/${linkLang}/${slug.toLowerCase()}/)`;
})
// Markdown-Links auf de-/en-Dateien ohne .md
.replace(/\]\((en|de)-([^)#]+)\)/g, (match, linkLang, slug) => {
return `](/manual/${linkLang}/${slug.toLowerCase()}/)`;
})
// Markdown links to German or English manual pages.
// The source may contain an optional ".md" suffix and an optional anchor.
// Both forms must be converted to the corresponding website manual URL.
.replace(
/\]\((en|de)-([^#)]+?)(?:\.md)?(?:#([^)]+))?\)/g,
(match, linkLang, slug, anchor) => {
const fragment = anchor ? `#${anchor}` : "";
// Markdown-Links auf de-/en-Dateien mit .md
.replace(/\]\((en|de)-([^)#]+)\.md\)/g, (match, linkLang, slug) => {
return `](/manual/${linkLang}/${slug.toLowerCase()}/)`;
});
return `](/manual/${linkLang}/${slug.toLowerCase()}/${fragment})`;
}
);
}
module.exports = function (eleventyConfig) {
+153
View File
@@ -0,0 +1,153 @@
const REPO = "praktimarc/kst4contest";
const API = `https://api.github.com/repos/${REPO}`;
const RELEASES_URL = `https://github.com/${REPO}/releases`;
/**
* Beta builds are published by .github/workflows/tagged-release.yml whenever
* a tag starting with "beta-" is pushed: it creates a GitHub prerelease with
* the same asset naming as a Stable release (based on the tag), except for
* the flatpakref, which is named ...beta.flatpakref instead of .flatpakref.
*
* There is no dedicated "beta" marker in the GitHub API beyond the
* prerelease flag, but that flag is exactly what this workflow sets, and
* nothing else in this repository publishes prereleases, so it is a safe
* signal to use here.
*
* A prerelease flag alone isn't enough though: GitHub never clears
* `prerelease` once the corresponding Stable version has actually shipped,
* so the latest prerelease can be stale (e.g. beta-1.41-rc04 published
* 2026-06-30, followed by Stable v1.41.0 on 2026-07-01). If the newest
* Stable release is more recent than the newest prerelease, there is no
* current beta and the empty state should be shown instead.
*/
async function fetchLatestBetaRelease() {
const headers = { Accept: "application/vnd.github+json" };
if (process.env.GITHUB_TOKEN) {
headers.Authorization = `Bearer ${process.env.GITHUB_TOKEN}`;
}
try {
const res = await fetch(`${API}/releases?per_page=10`, { headers });
if (!res.ok) {
throw new Error(`GitHub API /releases failed: ${res.status}`);
}
const releases = await res.json();
const latestBeta = releases.find((release) => release.prerelease && !release.draft) || null;
const latestStable = releases.find((release) => !release.prerelease && !release.draft) || null;
if (!latestBeta) {
return null;
}
if (latestStable && latestStable.published_at > latestBeta.published_at) {
return null;
}
return latestBeta;
} catch (err) {
console.warn(
`[beta] Could not load the latest beta release. ` +
`The Beta tab will show its empty state instead: ${err.message}`
);
return null;
}
}
function unavailable() {
return {
available: false,
releasesUrl: RELEASES_URL,
items: []
};
}
/**
* Builds the Beta download list from the most recent GitHub prerelease.
* If there is currently no Beta release, the Beta tab is expected to show
* nothing but an explanatory empty state rather than guessed-at links.
*/
module.exports = async function () {
const release = await fetchLatestBetaRelease();
if (!release) {
return unavailable();
}
const tag = release.tag_name;
const assetUrl = (filenameTemplate) =>
`https://github.com/${REPO}/releases/download/${tag}/${filenameTemplate.replace(/\{tag\}/g, tag)}`;
const items = [
{
os: "Windows",
format: "ZIP x64",
icon: "🪟",
note: "Extract the archive, then start praktiKST.exe. No separate Java installation is required.",
url: assetUrl("praktiKST-{tag}-windows-x64.zip")
},
{
os: "Linux",
format: "Flatpak (.flatpakref)",
icon: "🐧",
note: "Installs the beta branch of the Flatpak repo through Flatpak or the desktop software centre.",
url: assetUrl("de.x08.KST4Contest.beta.flatpakref")
},
{
os: "Linux",
format: "AppImage x86_64",
icon: "🐧",
note: "Portable build without package installation. Make the downloaded file executable before the first launch.",
url: assetUrl("KST4Contest-{tag}-linux-x86_64.AppImage")
},
{
os: "Debian / Ubuntu",
format: "DEB amd64",
icon: "📦",
note: "Native package for Debian, Ubuntu and distributions based on them.",
url: assetUrl("KST4Contest-{tag}-debian-amd64.deb")
},
{
os: "Fedora",
format: "RPM x86_64",
icon: "📦",
note: "Native package built for Fedora and compatible RPM-based systems.",
url: assetUrl("KST4Contest-{tag}-fedora-x86_64.rpm")
},
{
os: "Arch Linux",
format: "pkg.tar.zst",
icon: "📦",
note: "Release package for direct installation with pacman.",
url: assetUrl("KST4Contest-{tag}-archlinux-x86_64.pkg.tar.zst")
},
{
os: "macOS Apple Silicon",
format: "DMG arm64",
icon: "🍎",
note: "Best-effort build for Apple Silicon Macs. Not currently notarized by Apple.",
url: assetUrl("KST4Contest-{tag}-macos-arm64.dmg")
},
{
os: "macOS Intel",
format: "DMG x86_64",
icon: "🍎",
note: "Best-effort build for Intel Macs. Not currently notarized by Apple.",
url: assetUrl("KST4Contest-{tag}-macos-x86_64.dmg")
}
];
return {
available: true,
releasesUrl: RELEASES_URL,
tag,
name: release.name,
publishedAt: release.published_at,
releaseUrl: release.html_url,
items
};
};
+191
View File
@@ -0,0 +1,191 @@
const REPO = "praktimarc/kst4contest";
const API = `https://api.github.com/repos/${REPO}`;
const WORKFLOW_FILE = "nightly-artifacts.yml";
const WORKFLOW_BASENAME = "nightly-artifacts";
const BRANCH = "main";
const WORKFLOW_RUNS_URL = `https://github.com/${REPO}/actions/workflows/${WORKFLOW_FILE}`;
/**
* nightly.link (https://nightly.link) mirrors the most recent successful
* GitHub Actions artifact for a given workflow/branch/artifact-name as a
* plain public download, with no GitHub account required. It always follows
* the latest successful run on its own, so these URLs stay correct without
* this site having to resolve a run ID at build time.
*/
const NIGHTLY_LINK_BASE = `https://nightly.link/${REPO}/workflows/${WORKFLOW_BASENAME}/${BRANCH}`;
/**
* Static metadata for the artifacts produced by
* .github/workflows/nightly-artifacts.yml, keyed by the upload-artifact name
* used in that workflow. Anything not listed here (e.g. the raw
* flatpak-ostree-repo folder) is skipped on the nightly page.
*/
const ARTIFACT_INFO = {
"windows-zip": {
os: "Windows",
format: "ZIP x64",
icon: "🪟",
note: "Extract the archive, then start praktiKST.exe. No separate Java installation is required.",
order: 1
},
"linux-appimage": {
os: "Linux",
format: "AppImage x86_64",
icon: "🐧",
note: "Portable build. Make the downloaded file executable before the first launch.",
order: 2
},
flatpakref: {
os: "Linux",
format: "Flatpak (.flatpakref, nightly branch)",
icon: "🐧",
note: "Adds the nightly branch of the KST4Contest Flatpak repo. See the installation guide for the flatpak CLI alternative.",
order: 3
},
"linux-debian": {
os: "Debian / Ubuntu",
format: "DEB amd64",
icon: "📦",
note: "Native package for Debian, Ubuntu and distributions based on them.",
order: 4
},
"linux-fedora": {
os: "Fedora",
format: "RPM x86_64",
icon: "📦",
note: "Native package built for Fedora and compatible RPM-based systems.",
order: 5
},
"linux-arch": {
os: "Arch Linux",
format: "pkg.tar.zst",
icon: "📦",
note: "Package for direct installation with pacman.",
order: 6
},
"macos-dmg-macos-latest": {
os: "macOS Apple Silicon",
format: "DMG arm64",
icon: "🍎",
note: "Best-effort build for Apple Silicon Macs. Not notarized by Apple.",
order: 7
},
"macos-dmg-macos-15-intel": {
os: "macOS Intel",
format: "DMG x86_64",
icon: "🍎",
note: "Best-effort build for Intel Macs. Not notarized by Apple.",
order: 8
}
};
function buildItems() {
return Object.entries(ARTIFACT_INFO)
.map(([name, info]) => ({
...info,
name,
url: `${NIGHTLY_LINK_BASE}/${name}.zip`
}))
.sort((a, b) => a.order - b.order);
}
function authHeaders() {
const headers = { Accept: "application/vnd.github+json" };
if (process.env.GITHUB_TOKEN) {
headers.Authorization = `Bearer ${process.env.GITHUB_TOKEN}`;
}
return headers;
}
function formatSize(bytes) {
if (bytes < 1024 * 1024) {
return `${(bytes / 1024).toFixed(0)} KB`;
}
return `${(bytes / (1024 * 1024)).toFixed(1)} MB`;
}
/**
* Best-effort lookup of the run behind the current nightly.link downloads,
* purely to show a commit/date on the page. The download links themselves
* (buildItems) do not depend on this succeeding.
*/
async function fetchLatestRunMeta(headers) {
const runsRes = await fetch(
`${API}/actions/workflows/${WORKFLOW_FILE}/runs?branch=${BRANCH}&status=success&per_page=1`,
{ headers }
);
if (!runsRes.ok) {
throw new Error(`workflow runs request failed: ${runsRes.status}`);
}
const runsData = await runsRes.json();
const run = runsData.workflow_runs && runsData.workflow_runs[0];
if (!run) {
throw new Error("no successful nightly run found");
}
const meta = {
runUrl: run.html_url,
commitUrl: `https://github.com/${REPO}/commit/${run.head_sha}`,
shortSha: run.head_sha.slice(0, 7),
createdAt: run.created_at
};
try {
const artifactsRes = await fetch(
`${API}/actions/runs/${run.id}/artifacts?per_page=100`,
{ headers }
);
if (artifactsRes.ok) {
const artifactsData = await artifactsRes.json();
const sizeByName = {};
for (const artifact of artifactsData.artifacts || []) {
if (!artifact.expired) {
sizeByName[artifact.name] = formatSize(artifact.size_in_bytes);
}
}
meta.sizeByName = sizeByName;
}
} catch {
// Sizes are a nice-to-have; the run metadata above is still useful without them.
}
return meta;
}
module.exports = async function () {
const items = buildItems();
let meta = null;
try {
meta = await fetchLatestRunMeta(authHeaders());
} catch (err) {
console.warn(
`[nightly] Could not load latest nightly run metadata (commit/date will be omitted). ` +
`Download links are unaffected since they are served by nightly.link: ${err.message}`
);
}
if (meta && meta.sizeByName) {
for (const item of items) {
if (meta.sizeByName[item.name]) {
item.size = meta.sizeByName[item.name];
}
}
}
return {
runsUrl: WORKFLOW_RUNS_URL,
meta,
items
};
};
+180 -2
View File
@@ -10,6 +10,8 @@
--accent: #38bdf8;
--accent2: #a855f7;
--accent3: #22c55e;
--warn: #f59e0b;
--danger: #f43f5e;
--shadow: 0 24px 80px rgba(0, 0, 0, 0.45);
}
@@ -259,6 +261,7 @@ a:hover {
color: #020617;
background: linear-gradient(135deg, var(--accent), var(--accent2));
font-weight: 800;
cursor: pointer;
box-shadow:
0 16px 44px rgba(56, 189, 248, 0.25),
inset 0 1px 0 rgba(255, 255, 255, 0.35);
@@ -463,6 +466,181 @@ a:hover {
min-height: 220px;
}
.channel-picker {
margin: 34px 0 0;
}
.channel-switch {
display: inline-flex;
gap: 4px;
padding: 5px;
margin: 0 0 40px;
border: 1px solid var(--border);
border-radius: 999px;
background: rgba(2, 6, 23, 0.55);
}
.channel-option {
position: relative;
display: inline-flex;
}
.channel-option input {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}
.channel-option span {
display: inline-flex;
align-items: center;
gap: 8px;
padding: 11px 22px;
border-radius: 999px;
font-weight: 800;
color: var(--muted);
cursor: pointer;
transition: color 0.15s ease;
}
.channel-option input:checked + span {
color: #020617;
background: linear-gradient(135deg, var(--accent), var(--accent2));
box-shadow: 0 10px 30px rgba(56, 189, 248, 0.25);
}
.channel-option input:focus-visible + span {
outline: 2px solid var(--accent);
outline-offset: 2px;
}
.channel-panel {
display: none;
}
.channel-picker:has(#channel-stable:checked) .channel-panel[data-channel="stable"],
.channel-picker:has(#channel-beta:checked) .channel-panel[data-channel="beta"],
.channel-picker:has(#channel-nightly:checked) .channel-panel[data-channel="nightly"] {
display: block;
}
.notice-banner {
display: flex;
gap: 18px;
align-items: flex-start;
padding: clamp(18px, 3vw, 26px);
margin-bottom: 30px;
border: 1px solid var(--warn);
border-radius: 20px;
background: linear-gradient(180deg, rgba(245, 158, 11, 0.14), rgba(245, 158, 11, 0.04));
}
.notice-banner .disclaimer-icon {
font-size: 2rem;
}
.notice-banner h3 {
margin: 0 0 6px;
font-size: 1.1rem;
color: #fde68a;
}
.notice-banner p {
margin: 0;
color: var(--muted);
}
.empty-state {
text-align: center;
padding: clamp(30px, 5vw, 54px);
}
.empty-state .disclaimer-icon {
font-size: 2.4rem;
margin-bottom: 12px;
}
.empty-state h3 {
margin: 0 0 10px;
}
.empty-state p {
color: var(--muted);
max-width: 560px;
margin: 0 auto;
}
.empty-state .actions {
justify-content: center;
}
.disclaimer-banner {
display: flex;
gap: 20px;
align-items: flex-start;
padding: clamp(22px, 4vw, 34px);
margin-bottom: 34px;
border: 2px solid var(--danger);
border-radius: 22px;
background: linear-gradient(180deg, rgba(244, 63, 94, 0.16), rgba(244, 63, 94, 0.05));
box-shadow: 0 0 40px rgba(244, 63, 94, 0.16);
}
.disclaimer-icon {
flex: none;
font-size: 2.6rem;
line-height: 1;
}
.disclaimer-banner h3 {
margin: 0 0 8px;
font-size: 1.35rem;
color: #fecdd3;
}
.disclaimer-banner p {
margin: 0;
color: var(--text);
}
.disclaimer-banner p + p {
margin-top: 10px;
color: var(--muted);
}
.disclaimer-banner .inline-link {
color: #fecdd3;
text-decoration: underline;
cursor: pointer;
font-weight: 700;
}
.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}
.channel-panel .section-heading + .actions {
margin: -10px 0 30px;
}
.channel-panel .content-card {
margin-top: 30px;
}
.screenshot-placeholder {
display: grid;
place-items: center;
@@ -491,14 +669,14 @@ a:hover {
line-height: 1.2;
}
.manual-content pre {
pre {
overflow-x: auto;
padding: 16px;
border-radius: 14px;
background: #020617;
}
.manual-content code {
code {
color: #bae6fd;
}
+202 -27
View File
@@ -1,45 +1,214 @@
---
layout: base.njk
title: Download KST4Contest
description: Download the latest stable KST4Contest packages for Windows, Linux and macOS. The required Java runtime is included.
description: Download the latest stable KST4Contest packages for Windows, Linux and macOS, or switch to a nightly build for testing. The required Java runtime is included.
---
<section class="hero">
<p class="badge">Stable release</p>
<p class="badge">Stable, Beta &amp; Nightly channels</p>
<h1>Download KST4Contest</h1>
<p class="lead">
Choose the package for your operating system. Official builds are published through GitHub Releases,
and the required Java runtime is already included.
Choose the package for your operating system. The required Java runtime is already included. Use
the switch below to pick between the Stable release, Beta and current Nightly builds.
</p>
<div class="actions">
<a class="button" href="https://github.com/praktimarc/kst4contest/releases/latest">Latest release on GitHub</a>
<a class="button secondary" href="https://github.com/praktimarc/kst4contest/releases">All releases</a>
</div>
</section>
<section class="section">
<div class="section-heading">
<p class="eyebrow">Packages by platform</p>
<h2>Choose the format that fits your system</h2>
</div>
<div class="channel-picker">
<fieldset class="channel-switch">
<legend class="sr-only">Choose a build channel</legend>
<label class="channel-option">
<input type="radio" name="channel" id="channel-stable" checked>
<span>Stable release</span>
</label>
<label class="channel-option">
<input type="radio" name="channel" id="channel-beta">
<span>Beta{% if beta.available %} · {{ beta.tag }}{% endif %}</span>
</label>
<label class="channel-option">
<input type="radio" name="channel" id="channel-nightly">
<span>Nightly builds</span>
</label>
</fieldset>
<div class="grid">
{% for item in downloads %}
<article class="card download-card">
<div class="feature-icon">{{ item.icon }}</div>
<div class="channel-panel" data-channel="stable">
<div class="section-heading">
<p class="eyebrow">Packages by platform</p>
<h2>Choose the format that fits your system</h2>
</div>
{% if item.recommended %}
<p class="badge">Default choice</p>
{% endif %}
<div class="actions">
<a class="button" href="https://github.com/praktimarc/kst4contest/releases/latest">Latest release on GitHub</a>
<a class="button secondary" href="https://github.com/praktimarc/kst4contest/releases">All releases</a>
</div>
<h3>{{ item.os }}</h3>
<p><strong>{{ item.format }}</strong></p>
<p>{{ item.note }}</p>
<div class="grid">
{% for item in downloads %}
<article class="card download-card">
<div class="feature-icon">{{ item.icon }}</div>
<a class="button secondary" href="{{ item.url }}">Download →</a>
</article>
{% endfor %}
{% if item.recommended %}
<p class="badge">Default choice</p>
{% endif %}
<h3>{{ item.os }}</h3>
<p><strong>{{ item.format }}</strong></p>
<p>{{ item.note }}</p>
<a class="button secondary" href="{{ item.url }}">Download →</a>
</article>
{% endfor %}
</div>
</div>
<div class="channel-panel" data-channel="beta">
{% if beta.available %}
<div class="notice-banner">
<div class="disclaimer-icon" aria-hidden="true">🧪</div>
<div>
<h3>Pre-release — do a quick check before a contest</h3>
<p>
Beta builds have a largely defined feature set and are used for focused testing ahead of
a Stable release. They can still contain new defects. If you plan to use one on contest
day, try it beforehand.
</p>
</div>
</div>
<div class="section-heading">
<p class="eyebrow">Current beta</p>
<h2>{{ beta.name or beta.tag }} · {{ beta.publishedAt | dateToIso }}</h2>
</div>
<p class="lead">
<a href="{{ beta.releaseUrl }}">View this release on GitHub</a>
</p>
<div class="grid">
{% for item in beta.items %}
<article class="card download-card">
<div class="feature-icon">{{ item.icon }}</div>
<h3>{{ item.os }}</h3>
<p><strong>{{ item.format }}</strong></p>
<p>{{ item.note }}</p>
<a class="button secondary" href="{{ item.url }}">Download →</a>
</article>
{% endfor %}
</div>
<div class="card content-card">
<h3>Flatpak beta channel</h3>
<p>
Instead of the .flatpakref download above, Flatpak users can also track the beta channel
directly through the CLI once the Stable repo is already added:
</p>
<pre><code>flatpak install kst4contest de.x08.KST4Contest//beta</code></pre>
<p>
See the <a href="/manual/en/installation/">installation guide</a> for the full Flatpak setup.
</p>
</div>
{% else %}
<div class="card content-card empty-state">
<div class="disclaimer-icon" aria-hidden="true">🧪</div>
<h3>No Beta build right now</h3>
<p>
There is currently no Beta release. Beta builds are published occasionally for focused
testing ahead of a Stable release, tagged separately from Nightly builds. Check back later,
or use the Stable release or a Nightly build in the meantime.
</p>
<div class="actions">
<label for="channel-stable" class="button secondary">Switch to Stable</label>
<label for="channel-nightly" class="button ghost">Switch to Nightly</label>
<a class="button ghost" href="{{ beta.releasesUrl }}">All releases on GitHub</a>
</div>
</div>
{% endif %}
</div>
<div class="channel-panel" data-channel="nightly">
<div class="disclaimer-banner">
<div class="disclaimer-icon" aria-hidden="true">⚠️</div>
<div>
<h3>Testing only — not for contest operation</h3>
<p>
Nightly builds are automated, unreviewed snapshots of the <code>main</code> branch. They can
be unstable, contain unfinished features, break your settings or corrupt log data. Do not
rely on a nightly build during a contest.
</p>
<p>
Use the <label for="channel-stable" class="inline-link">Stable release</label> for actual
operation. Nightly builds exist to test a specific fix or feature ahead of the next release.
</p>
</div>
</div>
<div class="section-heading">
<p class="eyebrow">
{% if nightly.meta %}
Latest successful build
{% else %}
Current nightly build
{% endif %}
</p>
<h2>
{% if nightly.meta %}
Build {{ nightly.meta.shortSha }} · {{ nightly.meta.createdAt | dateToIso }}
{% else %}
Always points to the newest successful workflow run
{% endif %}
</h2>
</div>
{% if nightly.meta %}
<p class="lead">
From commit <a href="{{ nightly.meta.commitUrl }}"><code>{{ nightly.meta.shortSha }}</code></a> ·
<a href="{{ nightly.meta.runUrl }}">view this workflow run on GitHub</a>
</p>
{% else %}
<p class="lead">
Commit and date details could not be loaded when this page was built. The download links below
are unaffected — nightly.link always resolves to the latest successful run on its own.
</p>
{% endif %}
<div class="grid">
{% for item in nightly.items %}
<article class="card download-card">
<div class="feature-icon">{{ item.icon }}</div>
<h3>{{ item.os }}</h3>
<p><strong>{{ item.format }}</strong></p>
<p>{{ item.note }}</p>
{% if item.size %}<p><small>{{ item.size }}</small></p>{% endif %}
<a class="button secondary" href="{{ item.url }}">Download →</a>
</article>
{% endfor %}
</div>
<div class="card content-card">
<h3>How these downloads work</h3>
<p>
GitHub Actions build artifacts normally require a signed-in GitHub account to download. The
links above go through <a href="https://nightly.link/">nightly.link</a>, a public, open-source
proxy that mirrors the most recent successful build with no login required. Each link downloads
a <code>.zip</code> file; the actual installer, package or AppImage is inside and needs to be
extracted once.
</p>
<p>
Instead of the .flatpakref download, Flatpak users can also track the nightly channel directly
through the CLI once the Stable or Beta repo is already added:
</p>
<pre><code>flatpak install kst4contest de.x08.KST4Contest//nightly</code></pre>
<p>
See the <a href="/manual/en/installation/">installation guide</a> for how the Stable, Beta and
Nightly channels relate to each other, and for the full Flatpak setup. Older or in-progress
builds can be browsed on the
<a href="{{ nightly.runsUrl }}">nightly workflow run list on GitHub</a>.
</p>
</div>
</div>
</div>
</section>
@@ -77,4 +246,10 @@ description: Download the latest stable KST4Contest packages for Windows, Linux
<a class="button" href="/support/">Support the project</a>
</div>
</div>
</section>
</section>
<script>
var channelTabByHash = { "#beta": "channel-beta", "#nightly": "channel-nightly" };
var channelTab = document.getElementById(channelTabByHash[location.hash]);
if (channelTab) { channelTab.checked = true; }
</script>
+42 -8
View File
@@ -1,25 +1,59 @@
---
title: Log Synchronization
title: Log Synchronisation
icon: 🔄
category: Logger Integration
since: "1.31"
summary: Import worked stations and current frequencies from supported contest loggers so filters and band information follow the log.
description: KST4Contest receives worked-station and, where supported, frequency data from UCXLog, N1MM+, QARTest, DXLog.net and Win-Test through file and UDP interfaces.
summary: Import callsign, band, locator and QRG information from supported contest loggers at the level provided by each interface.
description: KST4Contest connects chat activity with current log state through file-based evaluation, general QSO UDP packets and the native Win-Test network protocol.
tagsList:
- Win-Test
- UCXLog
- N1MM+
- QARTest
- DXLog.net
- contest logger
related:
- priority-score
- dual-chat
- sked-reminder
---
## Connect chat and logging
## Why connect the logger?
Contest operation is faster when chat information and log state are connected.
The chat may still show a station as an interesting candidate after the QSO has already been logged. Without synchronisation, Worked filters, band columns and priority calculations would continue to use an outdated contest state.
KST4Contest can use logger information to improve workflow awareness.
KST4Contest therefore imports the information provided by the logging application and applies it to the active chat entries of the corresponding base callsign.
## Worked and band awareness
## Three interfaces with different levels of detail
Log synchronization helps the client understand which stations and bands are relevant.
The available information depends on the interface:
| Interface | Callsign | Band | Locator |
|---|---:|---:|---:|
| Simplelogfile interpreter | yes | no | no |
| General QSO UDP listener | yes | when included | when included |
| Win-Test network listener | yes | yes | when included |
The Simplelogfile interpreter is broadly compatible but can only identify worked callsigns. A callsign match in a file does not provide enough information to infer a reliable band or grid square.
The general UDP listener processes packets from UCXLog, N1MM+, QARTest and DXLog.net. Where the packet contains band and locator data, KST4Contest also updates the per-band Worked state and worked grid square.
![Log synchronisation settings](/manual/assets/client_settings_window_logsync.png)
## Native Win-Test integration
Win-Test uses a separate listener for its native network protocol. KST4Contest resolves the Win-Test band ID, including 50 and 70 MHz, and stores the resulting Worked information in the same internal database.
STATUS packets can also update the local QRG. In multi-operator networks, a station-name filter prevents STATUS packets from another operating position from replacing the frequency of the intended radio.
Win-Test can additionally receive skeds created in KST4Contest. The handover only takes place when a QRG matching the selected band can be determined. No fixed fallback frequency is inserted merely to make the packet technically valid.
> The band-aware sked handover and explicit `SSB`/`CW` selection are included in Nightly / v1.42.
## Stored state and limitations
Worked, NOT-QRV and worked-grid information is stored in the internal SQLite database and restored after a restart. Contest-related records expire automatically after three days.
KST4Contest can only use the fields supplied by the selected interface. Missing band or locator data is not reconstructed from guesswork. This makes the result less complete in some cases, but also avoids turning an incomplete log packet into incorrect Worked information.
[Read the complete log synchronisation setup in the manual.](/manual/en/log-sync/)
+36 -7
View File
@@ -3,8 +3,8 @@ title: Priority Score System
icon: 🎯
category: Contest Workflow
since: "1.40"
summary: Rank active stations from known context such as direction, activity, band, QRG, AP and sked information.
description: The Priority Score System combines available contest information to populate a separate list of currently relevant candidates.
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.
tagsList:
- ON4KST
- VHF
@@ -18,12 +18,41 @@ related:
- sked-reminder
---
## Why it matters
## The problem behind the score
During active VHF, UHF and microwave contests, relevant stations can disappear quickly in busy ON4KST chat traffic.
An ON4KST user list shows who is logged in. During a contest, the more useful question is which station should be examined next.
The Priority Score System helps operators focus on stations that are more likely to be useful during contest operation.
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.
## Built for contest decisions
## How candidates are selected
KST4Contest is not just a chat viewer. It evaluates contest-relevant context and helps turn chat activity into better operating decisions.
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.
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 remaining stations are ranked using several independent hints, including:
- 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.
An imminent sked receives a deliberately strong boost. Failed attempts and unanswered calls reduce the score.
## One station, several chat logins
Suffixes and chat categories remain separate message targets. Worked, band, NOT-QRV and score information is shared through the normalised base callsign.
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.
![Priority Score, compact candidate list and Further Info controls](/manual/assets/priority_score_overview.png)
## A decision aid, not a propagation forecast
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.
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.
[Read the complete calculation and its limitations in the manual.](/manual/en/features/#priority-score-and-priority-list-from-v140)
+53 -7
View File
@@ -3,24 +3,70 @@ title: Sked Reminder
icon: 🔔
category: Sked Management
since: "1.40"
summary: Store planned contacts and issue configurable chat messages plus local alerts before the agreed time.
description: Sked Reminder keeps scheduled contacts visible and provides automatic advance messages together with acoustic and visual operator alerts.
summary: Create a timed contact, raise its priority, show it on the timeline and optionally send reminder PMs before the agreed time.
description: KST4Contest keeps scheduled contacts in the active workflow, increases their priority as the agreed time approaches and can remind both operators.
tagsList:
- sked
- ON4KST
- contest reminder
- Win-Test
related:
- priority-score
- airscout
- timeline
---
## Never lose important skeds
## Why store a sked inside the chat client?
During active contests, it is easy to miss a planned contact while handling chat traffic, logging and band changes.
A contact agreed for five or ten minutes later has to compete with incoming messages, logging, antenna changes and other stations asking for attention. Remembering the time is only part of the problem. The station must also become visible again when the appointment approaches.
Sked Reminder keeps scheduled contacts visible.
KST4Contest therefore treats a sked as an active operating task rather than a simple alarm.
## Built for real contest pressure
## What happens when a sked is created?
The workflow supports time-critical operation where missing a few minutes can mean missing a QSO.
Select the station, the remaining time and one of the locally enabled bands. The mode can be set to `SSB` or `CW` for a possible Win-Test handover.
After pressing **Create sked**, KST4Contest:
1. stores the sked internally,
2. raises the station's Priority Score as the scheduled time approaches,
3. adds the contact to the AP and sked timeline, and
4. optionally schedules private reminder messages.
![Sked controls in the Further Info section](/manual/assets/sked_controls.png)
The internal sked does not depend on Win-Test. If no logger is connected or the network handover fails, the sked remains available in KST4Contest.
## Reminding the remote station
Reminder PMs are optional. The available patterns are:
- two and one minute before the sked,
- five, two and one minute before the sked, or
- ten, five, two and one minute before the sked.
Messages are sent to the complete KST callsign in the selected chat category. A band-specific login such as `CALLSIGN-70` therefore remains a separate message target instead of being silently reduced to the base callsign.
The local operator receives a visual **SKED** indication and, if simple notification sounds are enabled, an acoustic reminder.
## Win-Test handover
When the Win-Test network listener is enabled, KST4Contest also attempts to send the sked to Win-Test.
The frequency is not guessed. KST4Contest first looks for a recent QRG of the remote station on the selected band. If none is available, it checks whether the local QRG of the selected chat category belongs to that band. Without a matching frequency, the Win-Test handover is omitted while the internal sked remains intact.
KST-specific suffixes such as `-2`, `-70` or `-144` are removed from the callsign passed to the log. Portable components such as `/P` and `/M` are preserved.
> Band-aware QRG validation, explicit `SSB`/`CW` selection and the corrected handling of KST suffixes are included in Nightly / v1.42.
![Sked handed over from KST4Contest to Win-Test](/manual/assets/wintest_sked_handover.png)
## What the reminder cannot guarantee
Skeds and reminder schedules are stored in memory. They must be recreated after restarting KST4Contest.
The proposed band is derived from recent chat and station-name information. This is useful context, not proof that the station is still operating on the same QRG. Check the band, time and mode before creating the sked.
In plain terms: the function makes a scheduled contact considerably harder to overlook. It cannot prevent every missed sked.
[Read the complete sked handling and its limitations in the manual.](/manual/en/features/#skeds-and-sked-reminders)
+38 -9
View File
@@ -1,25 +1,54 @@
---
title: Timeline View
title: AP and Sked Timeline
icon: ⏱️
category: Contest Awareness
since: "1.40"
summary: Show AP-based priority candidates and scheduled contacts on a shared timeline.
description: The Timeline View places upcoming aircraft scatter candidates and planned skeds into a common time-based overview.
summary: Show upcoming aircraft-scatter candidates and scheduled contacts together on a 30-minute timeline.
description: The timeline relates AirScout opportunities, priority candidates, antenna direction and internal skeds to their expected time.
tagsList:
- timeline
- AP windows
- airplane scatter
- aircraft scatter
- sked
related:
- airscout
- priority-score
- sked-reminder
---
## Timing matters
## The useful station may only be useful for a minute
Many VHF/UHF/SHF opportunities are short-lived.
Aircraft-scatter opportunities are time-dependent. A candidate which matters in two minutes may be irrelevant now, while an agreed sked must remain visible even when no aircraft is currently available.
The Timeline View helps operators see upcoming timing windows instead of keeping everything in mind manually.
The timeline places both kinds of event into the same 30-minute view.
## Designed for fast awareness
Events further in the future appear on the right. As their time approaches, they move left towards the present.
The timeline supports quick decisions during busy contest operation.
![AP candidates and skeds in the timeline](/manual/assets/sked_timeline.png)
## AP candidates and scheduled contacts remain distinct
AP candidates appear in the upper lanes. Up to four selected candidates can be shown for each arrival minute. Their colours represent the reflection potential reported by AirScout:
- magenta from 95%,
- red from 75%,
- yellow from 50%, and
- blue below 50%.
Skeds appear as diamonds in the lower lane. Their labels use the complete selected KST callsign so that band-specific or otherwise suffixed logins remain identifiable.
> Complete KST callsigns in sked labels are included in Nightly / v1.42.
## Antenna direction remains visible
A marker becomes more transparent when its QTF is clearly outside the current antenna direction. The callsign remains readable. Targets near the centre of the configured antenna beam receive an additional visual highlight.
Clicking an AP candidate selects the corresponding active chat member, including the callsign suffix and chat category.
## A timing aid, not a contact forecast
The timeline shows when an event is expected to matter. It does not guarantee that the frequency is clear, that the remote station is ready or that the calculated aircraft path will produce a workable signal.
AirScout data can change. So can the actual operating situation.
[Read the complete timeline behaviour in the manual.](/manual/en/features/#ap-and-sked-timeline)