manual: described pm catching better...

github_docs/de-Benutzeroberflaeche.md

@@ -56,9 +56,18 @@ Beide Hinweise blinken ungefähr zwölf Sekunden und verschwinden anschließend
 
 Das PM-Fenster zeigt die an die eigenen Chat-Logins gerichteten Privatnachrichten und die zugehörigen ausgehenden Antworten.
 
+Nicht selbst gesendete Nachrichten erscheinen dort zusätzlich, wenn ihr Text ohne Beachtung der Groß- und Kleinschreibung das konfigurierte eigene Login-Rufzeichen enthält. Das gilt für öffentliche Nachrichten an `ALL` ebenso wie für gerichtete Nachrichten zwischen anderen Chatteilnehmern. Gerade im zweiten Fall lässt sich dieses PM-Catching flapsig als **„Lästererkennung“** bezeichnen.
+
+Der tatsächliche Empfänger, der Nachrichtentext, die Chat-Kategorie und das Routing bleiben unverändert. Die Nachricht erhält lediglich eine zusätzliche Darstellung im PM-Fenster.
+
 Ist das [QSO-Monitoring](de-Funktionen#qso-monitoring-ab-v131) aktiviert, erscheinen dort zusätzlich die erfassten Nachrichten der überwachten Basisrufzeichen. Diese Einträge erhalten eine `Sniffed:`-Kennzeichnung mit dem vollständigen sichtbaren Absender und Empfänger.
 
-Neue Nachrichten werden zunächst auffällig dargestellt und wechseln anschließend schrittweise zur normalen Tabellenfarbe. Die farbliche Hervorhebung dient nur als zeitlicher Hinweis; sie verändert weder Inhalt noch Routing der Nachricht.
+Neue, nicht selbst gesendete Zeilen durchlaufen sechs grüne Altersstufen und kehren nach fünf Minuten zur normalen Tabellenfarbe zurück. Eigene Nachrichten behalten ihre separate Hervorhebung. Die farbliche Darstellung ist nur ein zeitlicher Hinweis; sie verändert weder Inhalt noch Routing der Nachricht.
+
+Die Auswahl einer eingehenden Zeile bereitet eine Antwort an den Absender vor. Bei einer eigenen ausgehenden Nachricht wird stattdessen der ursprüngliche Empfänger als Nachrichtenziel wiederhergestellt. Caught- und Monitoring-Zeilen lösen keine PM-Audioausgabe aus.
+
+Altersstufen: [Farbige PM-Zeilen](de-Funktionen#farbige-pm-zeilen-ab-v125). Erkennung und Grenzen: [PM-Abfang](de-Funktionen#pm-abfang-catching-personal-messages-ab-v11).
+
 ### Benutzerliste (Chat Members)
 
 Die zentrale Tabelle aller aktuell aktiven Chat-Nutzer. Spalten (je nach Konfiguration):

github_docs/de-Contest-Workflow.md

@@ -246,6 +246,19 @@ G1YBB verwendet die Richtungsanzeige besonders konsequent. Grün markierte Stati
 
 KST4Contest automatisiert dabei nicht das QSO. Der Vorteil besteht darin, dass QRG, Richtung, Aircraft-Scatter-Informationen und weitere Bewertungsdaten bereits vorliegen, wenn die Gelegenheit entsteht. Die verbleibende Aufgabe ist eine schnelle betriebliche Entscheidung.
 
+Eine weitere, besonders konsequente Betriebsweise nutzt die Stationskarte als geografische Arbeitsliste:
+
+1. Der **wkd**-Filter blendet bereits gearbeitete Rufzeichen aus der Benutzerliste und damit auch aus der Karte aus.
+2. G1YBB wählt eine interessante Station auf der Karte aus.
+3. **Trigger cluster spot** übergibt die bekannte QRG an Minos.
+4. Ein Klick auf den Spot wechselt in Minos auf diese QRG.
+5. Nach dem QSO wird der Kontakt geloggt.
+6. Die Log-Synchronisation aktualisiert den Worked-Status; der Filter entfernt die Station anschließend aus Benutzerliste und Karte.
+
+Die Karte wird so zu einer räumlichen Liste der noch abzuarbeitenden Stationen. Dieser Ablauf ist optional. Er setzt eine zuverlässig eingerichtete Log-Synchronisation und DX-Cluster-Verbindung voraus und ist vor allem für Operatoren interessant, die den Contest bewusst auf diese geografische Weise strukturieren möchten.
+
+[G1YBB zeigt diesen Workflow im Video.](https://www.youtube.com/watch?v=BCNCjowPgec)
+
 ---
 
 ## Optionale Schnittstellen im Workflow

github_docs/de-DX-Cluster-Server.md

@@ -242,5 +242,6 @@ Die Schnittstelle wurde mit folgenden Logprogrammen verwendet:
 
 - UCXLog
 - N1MM+
+- Minos
 
 Weitere Logger können funktionieren, wenn sie eine normale TCP-Verbindung zu einem DX-Cluster-Server unterstützen.

github_docs/de-Funktionen.md

@@ -23,6 +23,10 @@ Angenommen, Station A schreibt eine gerichtete Nachricht an Station B:
 
 Ein eingetragener Öffnungswinkel von `70°` ergibt damit einen angenommenen Korridor von jeweils `35°` links und rechts der Richtung von Station A zu Station B.
 
+![Geometrie der angenommenen Antennenkorridore](directional_opportunity_geometry.png)
+
+Im dargestellten Beispiel verläuft der grüne Korridor von F5FEN in Richtung DM5M. Sendet F5FEN eine gerichtete Nachricht an DM5M, prüft KST4Contest, ob die eigene Station innerhalb dieses Korridors liegt. Bei einer Antwort von DM5M an F5FEN wird die Richtung neu berechnet: Dann beginnt der blaue Korridor bei DM5M und zeigt in Gegenrichtung auf F5FEN. Bewertet wird also bei jeder Nachricht die angenommene Antennenrichtung des jeweiligen Absenders.
+
 | Beispiel | Ergebnis |
 |---|---|
 | Richtung A → B: `120°`, Richtung A → eigene Station: `145°` | Winkeldifferenz `25°`: Richtungsgelegenheit erkannt |
@@ -233,7 +237,7 @@ Die Filter oberhalb der Benutzerliste greifen auf dieselben Informationen zurüc
 
 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).
+Bedienung und Aufbau der Filterleiste: [Benutzeroberfläche – Filter](de-Benutzeroberflaeche#filter-und-reachability-steuerung).
 
 ---
 
@@ -259,7 +263,7 @@ Eigene Nachrichten erhalten weiterhin eine separate Hervorhebung und verwenden n
 
 ---
 
-## PM-Abfang (Catching Personal Messages)
+## PM-Abfang (Catching Personal Messages, ab v1.1)
 
 Manche Nutzer senden Direktnachrichten versehentlich öffentlich, z. B.:
 
@@ -267,7 +271,17 @@ Manche Nutzer senden Direktnachrichten versehentlich öffentlich, z. B.:
 (DM5M) pse ur qrg
 ```
 
-KST4Contest erkennt solche Nachrichten, die das eigene Rufzeichen enthalten, und sortiert sie automatisch in die **Privatnachrichten-Tabelle** ein. So gehen keine Nachrichten verloren.
+KST4Contest sucht im Text aller nicht selbst gesendeten Nachrichten ohne Beachtung der Groß- und Kleinschreibung nach dem konfigurierten eigenen Login-Rufzeichen. Ein Treffer erscheint zusätzlich in der **Privatnachrichten-Tabelle**. Das gilt sowohl für öffentliche Nachrichten an `ALL` als auch für gerichtete Nachrichten zwischen anderen Chatteilnehmern.
+
+Gerade bei einer fremden gerichteten Nachricht wirkt das etwas wie **„Lästererkennung“**. Das ist eine flapsige Nebenbezeichnung, kein formaler Funktionsname.
+
+Die ursprüngliche Nachricht bleibt unverändert: Der tatsächliche Empfänger bleibt `ALL` beziehungsweise der andere Chatteilnehmer; auch Text, Chat-Kategorie und Routing bleiben erhalten. PM-Catching ergänzt nur eine weitere Ansicht derselben Nachricht.
+
+Die Textsuche versteht keine Absicht. Ein Schreibfehler oder ein verkürztes Rufzeichen wird nicht erkannt. Umgekehrt kann eine bloße Erwähnung des vollständig geschriebenen Rufzeichens einen Treffer erzeugen, obwohl keine Antwort erwartet wird.
+
+Wird eine eingehende Zeile in der PM-Tabelle ausgewählt, bereitet KST4Contest eine Antwort an ihren Absender vor. Bei einer eigenen ausgehenden Nachricht wird stattdessen der ursprüngliche Empfänger als Ziel wiederhergestellt. Die Auswahl versendet noch keine Nachricht.
+
+Auch abgefangene Zeilen verwenden die normale Altersanzeige der PM-Tabelle. Sie lösen jedoch weder den einfachen PM-Hinweiston noch die CW- oder Sprachausgabe für ein eingehendes Rufzeichen aus. Dasselbe gilt für Nachrichten, die durch das QSO-Monitoring zusätzlich in der PM-Tabelle erscheinen.
 
 ---
 

github_docs/de-Konfiguration.md

@@ -332,6 +332,8 @@ 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.
 
+Die PM-bezogenen Audioausgaben reagieren nur auf Nachrichten, die tatsächlich an das eigene Login-Rufzeichen gerichtet sind. Öffentliche Nachrichten, die durch PM-Catching zusätzlich in der PM-Tabelle erscheinen, und dort eingeblendete Monitoring-Nachrichten bleiben akustisch still.
+
 ### 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.

github_docs/en-Configuration.md

@@ -373,11 +373,15 @@ AirScout setup, aircraft display and the meaning of the returned AP information
 
 ![Notifications, DX cluster output and QSO monitoring](client_settings_window_notification.png)
 
-Three notification types are available:
+The three audio functions work independently:
 
-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.
+1. **Simple sounds**: Plays short cues for new private messages, detected directional opportunities, sked reminders and `BAND+` hints.
+2. **CW announcement**: Spells the sender's callsign in CW for a new private message.
+3. **Phonetic announcement**: Speaks the sender's callsign phonetically for a new private message.
+
+Each function can be enabled separately. CW and phonetic output can also be active at the same time.
+
+PM-related audio output is triggered only by messages actually directed to the local login callsign. Messages shown additionally through PM Catching and messages added through QSO Monitoring remain silent.
 
 ### Fallback Band for Relative QRG Detection
 

github_docs/en-Contest-Workflow.md

@@ -246,6 +246,19 @@ G1YBB uses the directional indication particularly consistently. Stations highli
 
 KST4Contest does not automate the QSO. Its advantage is that QRG, direction, aircraft scatter information and other evaluation data are already available when the opportunity appears. The remaining task is a quick operating decision.
 
+Another particularly consistent operating method uses the station map as a geographical worklist:
+
+1. The **wkd** filter removes already worked callsigns from the user list and therefore from the map.
+2. G1YBB selects an interesting station on the map.
+3. **Trigger cluster spot** passes the known QRG to Minos.
+4. Selecting the spot moves Minos to that QRG.
+5. The completed QSO is logged.
+6. Log synchronisation updates the Worked state, and the filter removes the station from both the user list and the map.
+
+The map consequently becomes a spatial list of the stations still to be worked. This workflow is optional. It requires reliable log synchronisation and a working DX Cluster connection and is mainly useful for operators who deliberately want to organise the contest in this geographical way.
+
+[Watch G1YBB demonstrate this workflow.](https://www.youtube.com/watch?v=BCNCjowPgec)
+
 ---
 
 ## Optional Interfaces in the Workflow

github_docs/en-DX-Cluster-Server.md

@@ -248,6 +248,7 @@ The interface has been used with:
 
 - UCXLog
 - N1MM+
+- Minos
 
 Other loggers may work if they support a normal TCP connection to a DX Cluster server and accept conventional `DX de ...` spot lines.
 

github_docs/en-Features.md

@@ -24,6 +24,10 @@ Assume that station A sends a directed message to station B:
 
 A configured beamwidth of `70°` therefore produces an assumed corridor of `35°` on either side of the direction from station A to station B.
 
+![Geometry of the assumed antenna corridors](directional_opportunity_geometry.png)
+
+In the example, the green corridor runs from F5FEN towards DM5M. When F5FEN sends a directed message to DM5M, KST4Contest checks whether the local station lies inside this corridor. A reply from DM5M to F5FEN is calculated again in the opposite direction: the blue corridor then starts at DM5M and points towards F5FEN. Each message therefore evaluates the assumed antenna direction of its sender.
+
 | Example | Result |
 |---|---|
 | Direction A → B: `120°`, direction A → local station: `145°` | Angular difference `25°`: directional opportunity detected |
@@ -232,7 +236,7 @@ The filters above the user list use the same information as the Worked columns:
 
 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).
+Operation and layout of the filter bar: [User Interface – Filters](en-User-Interface#filters-and-reachability-controls).
 
 ---
 
@@ -258,7 +262,7 @@ Messages sent by the local station retain their separate highlight and do not us
 
 ---
 
-## PM Catching
+## PM Catching (from v1.1)
 
 Some users accidentally post direct messages publicly, e.g.:
 
@@ -266,7 +270,17 @@ Some users accidentally post direct messages publicly, e.g.:
 (DM5M) pse ur qrg
 ```
 
-KST4Contest detects such messages that contain your own callsign and automatically sorts them into the **private messages table**. No messages are missed this way.
+KST4Contest searches the text of every message not sent by the local station for the configured local login callsign without distinguishing upper- and lower-case letters. A match also appears in the **private messages table**. This applies to public messages addressed to `ALL` and to directed messages between other chat participants.
+
+A directed message between two other stations is where the slightly flippant description **“gossip detection”** fits best. It is a nickname, not the formal name of the function.
+
+The original message remains unchanged: its actual receiver remains `ALL` or the other chat participant; its text, chat category and routing are retained as well. PM Catching merely adds another view of the same message.
+
+The text search cannot infer intention. A typing error or shortened callsign is not recognised. Conversely, a simple mention of the complete callsign can produce a match even when no reply was expected.
+
+Selecting an incoming row in the PM table prepares a reply to its sender. For an outgoing message from the local station, the original receiver is restored as the target instead. Selecting the row does not send the message.
+
+Caught rows use the normal PM-table age display. They do not trigger the simple PM sound, CW callsign output or phonetic callsign output. The same applies to messages shown additionally through QSO Monitoring.
 
 ---
 
@@ -802,7 +816,7 @@ Marker colours provide a compact status indication:
 |---|---|
 | Blue | Normal station marker |
 | Yellow | The callsign has already been worked on at least one band |
-| Green | The station is inside the current antenna sector and is relevant as a directional candidate |
+| Green | A directional opportunity has been derived for the station from directed chat messages |
 | Orange | Currently selected station |
 
 The selected state has the highest display priority, followed by the directional warning and Worked state. A selected station therefore remains orange even if it also meets one of the other conditions.

github_docs/en-User-Interface.md

@@ -56,9 +56,17 @@ Both indicators flash for approximately twelve seconds and then disappear. Their
 
 The PM window shows private messages addressed to the local chat logins and the corresponding outgoing replies.
 
+Messages not sent by the local station are also shown when their text contains the configured local login callsign, ignoring letter case. This applies to public messages addressed to `ALL` and to directed messages between other chat participants. The informal description **“gossip detection”** is particularly apt for the latter case.
+
+The actual receiver, message text, chat category and routing remain unchanged. The message merely gains an additional representation in the PM window.
+
 If [QSO Monitoring](en-Features#qso-sniffer-from-v131) is enabled, it additionally shows captured messages involving the monitored base callsigns. These entries receive a `Sniffed:` prefix containing the complete visible sender and receiver callsigns.
 
-New messages are initially highlighted and then gradually return to the normal table colour. This highlighting only indicates the age of the message; it does not change its content or routing.
+New rows not sent by the local station pass through six green age levels and return to the normal table colour after five minutes. Messages sent by the local station retain their separate highlight. The colour only indicates message age; it does not change content or routing.
+
+Selecting an incoming row prepares a reply to the sender. For an outgoing message from the local station, the original receiver is restored as the message target instead. Caught and monitored rows do not trigger PM audio output.
+
+Age levels: [Coloured PM Rows](en-Features#coloured-pm-rows-from-v125). Recognition and limitations: [PM Catching](en-Features#pm-catching-from-v11).
 
 ### User List (Chat Members)
 

website/src/features/airscout.md

@@ -15,6 +15,7 @@ tagsList:
   - SHF
   - contest
 related:
+  - station-filters
   - timeline
   - priority-score
   - sked-reminder
@@ -172,4 +173,4 @@ Conversely, a reported aircraft does not guarantee sufficient signal strength or
 
 [Read how the AP information affects the timeline.](/features/timeline/)
 
-[Open the AirScout project on GitHub.](https://github.com/dl2alf/AirScout)
+[Open the AirScout project on GitHub.](https://github.com/dl2alf/AirScout)

website/src/features/automatic-replies.md

@@ -13,6 +13,8 @@ tagsList:
   - sked request
   - dual chat
 related:
+  - private-message-handling
+  - trx-qrg-synchronisation
   - dual-chat
   - macros
   - sked-reminder
@@ -94,4 +96,4 @@ In plain terms: automatic replies remove repetitive typing. They do not take ove
 
 [Read the complete configuration and recognised QRG requests in the manual.](/manual/en/configuration/#messagehandling-settings-from-v125)
 
-[Read how two chat categories and suffixed callsigns are kept separate.](/features/dual-chat/)
+[Read how two chat categories and suffixed callsigns are kept separate.](/features/dual-chat/)

website/src/features/band-recognition.md

@@ -0,0 +1,93 @@
+---
+title: Band Recognition and Opportunities
+icon: 📶
+category: Contest Workflow
+since: "1.40"
+summary: Automatically recognise active bands and alert the operator immediately after logging when the same station can still be worked on another common band.
+description: KST4Contest combines QRGs, name fields, active callsign variants, local bands, Worked information and NOT-QRV marks to identify open band opportunities.
+tagsList:
+  - band recognition
+  - band opportunity
+  - BAND+
+  - Worked
+  - NOT QRV
+  - ON4KST
+  - contest workflow
+related:
+  - station-filters
+  - qrg-detection
+  - station-map
+  - directional-opportunities
+  - priority-score
+  - dual-chat
+  - log-sync
+---
+
+## Why does the moment after a QSO matter?
+
+Finding a station, turning the antenna, agreeing on a frequency and completing the QSO takes time. Once that contact is in the log, much of the difficult work has already been done.
+
+The first QSO has already demonstrated a usable path, correct antenna direction and an available operator. `BAND+` therefore appears immediately after logging when another common, unworked band is known, so the station can be moved before that operating context is lost. It does not guarantee the next band, but it identifies the best moment to try it.
+
+This sequence is the useful part: KST4Contest first recognises possible bands, compares them with the local station and the log, and then presents the remaining opportunity while both operators are still in contact.
+
+## How are active bands recognised?
+
+KST4Contest combines information which may be distributed across several chat entries:
+
+- QRGs detected for the remote station;
+- explicit band designators in its name fields; and
+- active callsign variants belonging to the same normalised base callsign.
+
+A recent QRG is stronger evidence than a general chat category. Active variants are evaluated together because a station may use separate suffixes or logins for different bands. The individual variants nevertheless remain separate message targets in their respective chat categories.
+
+## When does a detected band become an opportunity?
+
+Recognition alone is not enough. KST4Contest compares the detected bands with:
+
+1. the bands enabled for the local station;
+2. stored Worked information for each band; and
+3. manually assigned NOT-QRV marks.
+
+Only a locally enabled, common and unworked band remains an open opportunity. A manual NOT-QRV mark takes precedence over a detected QRG, name field or callsign variant.
+
+![Worked and band status in the user list](/manual/assets/not_qrv_controls.png)
+
+The comparison remains band-specific. Working a station on 144 MHz does not mark it as worked on 432 MHz, and a NOT-QRV mark for one band does not remove a different band opportunity.
+
+## Where is the result used?
+
+The same derived information supports several parts of the contest workflow:
+
+- `a` distinguishes an offered, unworked band for a callsign which has not yet been worked;
+- `B+` marks another offered, unworked band after the callsign has already been worked elsewhere; if the separate `a` display is disabled, it also represents this opportunity for a completely new callsign;
+- **New bands** filters the user list for stations with at least one detected opportunity;
+- the Priority Score uses known band compatibility and open band-upgrade cases;
+- map markers include derived bands and open `B+` opportunities; and
+- `BAND+` reports the remaining bands immediately after a suitable QSO is logged.
+
+These are not separate guesses. They use the same band, Worked and NOT-QRV context for different operating decisions.
+
+## The immediate `BAND+` hint
+
+When UCXLog or Win-Test reports a new QSO with band information, KST4Contest checks the station again. If another common and unworked band remains, a blinking hint appears for approximately twelve seconds, for example:
+
+```text
+BAND+ DL0ABC 432, 1296
+```
+
+The tooltip shows the enabled, worked and NOT-QRV bands behind the decision. If general notification sounds are enabled, a short sound accompanies the hint.
+
+The file-based Simplelogfile interpreter cannot trigger this hint reliably because it supplies the callsign but not the band of the newly logged QSO.
+
+## Recognition is evidence, not a promise
+
+A detected QRG, name-field entry or active callsign variant indicates possible activity. It is not proof that the station is currently ready on that band, that propagation will hold or that the next QSO will succeed.
+
+The reverse is equally important: unknown does not mean impossible. If KST4Contest has no band information for a station, it cannot present a known opportunity, but the missing information does not prove that no common band exists.
+
+In practical terms: band recognition reduces the time between noticing an opportunity and asking for the next band. The decision to try it still belongs to the operator.
+
+[Read how Worked, band and NOT-QRV information is derived in the manual.](/manual/en/features/#worked-callsigns-new-bands-and-new-grid-squares)
+
+[Open the `BAND+` and Priority Boost settings.](/manual/en/configuration/#band-upgrade-hint-after-a-log-entry)

website/src/features/directional-opportunities.md

@@ -0,0 +1,76 @@
+---
+title: Directional Opportunities
+icon: 📐
+category: Contest Workflow
+since: "1.1"
+summary: Recognise when a station in a directed ON4KST exchange may be pointing towards the local station and highlight the short-lived opportunity.
+description: KST4Contest derives a possible antenna direction from directed ON4KST messages and marks matching senders without requiring the local DX Cluster server.
+tagsList:
+  - ON4KST
+  - directional opportunity
+  - antenna direction
+  - beamwidth
+  - QRB
+  - contest workflow
+related:
+  - global-message-views
+  - station-map
+  - band-recognition
+  - dx-cluster
+  - rotator-control
+---
+
+## Why watch messages between other stations?
+
+A directed ON4KST message shows who is talking to whom. It does not include an antenna direction. During a contest, however, a station requesting, answering or preparing a sked will often point at least approximately towards the station being addressed.
+
+That creates a brief opportunity for stations near the same direction. KST4Contest has recognised this situation since version 1.1. The detection and user-list highlight work independently of the local DX Cluster server.
+
+## How is the opportunity derived?
+
+Assume that station A sends a directed message to station B. KST4Contest:
+
+1. calculates the direction from A to B and treats it as the likely antenna direction of A;
+2. calculates the direction from A to the local station;
+3. compares the angular difference with half of the configured antenna beamwidth; and
+4. checks that A is inside the configured maximum QRB.
+
+If the local station lies inside this assumed antenna corridor, A becomes a directional opportunity. A reply from B is a new case: the likely direction is then calculated from B back towards A.
+
+The configured beamwidth is the complete angle. With `70°`, KST4Contest therefore assumes a corridor of `35°` on either side of the direction between the two stations.
+
+## What does the operator see?
+
+The sender's callsign appears green and bold in the user list for five minutes. A later matching message restarts this period. If the station sends another directed message which no longer matches the geometry, the mark is removed immediately.
+
+![Detected directional opportunity in the user list](/manual/assets/direction_opportunity_highlight.png)
+
+When simple sound notifications are enabled, the first detection also produces a short acoustic indication. Further matching messages do not repeat the sound while the station is already marked.
+
+## What practical value does it have?
+
+The indication draws attention to a station at the moment when its antenna may already cover the local direction. It can be enough to notice a callsign which would otherwise remain one line among many in the chat.
+
+DM5M reports that around 35–40% of the directional opportunities used at that station have resulted in a QSO. This is station-specific operating experience, not a general success rate. Location, antenna patterns, propagation, contest activity and operating practice can produce very different results elsewhere.
+
+## Optional use in the logger bandmap
+
+Since version 1.23, KST4Contest can forward a detected opportunity and a known QRG through its local DX Cluster server. This is an optional second step. The direction calculation, green user-list mark and sound do not depend on a DX-Cluster connection.
+
+The local DX Cluster output reuses the result; it does not create the directional opportunity. If the server is disabled or no suitable QRG is known, the visual indication still works normally.
+
+## What does the indication not prove?
+
+ON4KST does not transmit the actual antenna direction or beamwidth of the remote station. KST4Contest therefore uses the locally configured antenna beamwidth as a practical approximation.
+
+The calculation also does not know the real antenna pattern, rotator position, terrain or current propagation. A matching corridor is not a propagation forecast and does not guarantee a QSO.
+
+In practical terms: the green callsign identifies a geometrically plausible moment to pay attention. Whether calling makes sense remains an operator decision.
+
+[Read the complete derivation and numerical examples in the manual.](/manual/en/features/#directional-opportunities-from-directed-messages)
+
+[Open the antenna beamwidth setting.](/manual/en/configuration/#antenna-beamwidth)
+
+[Open the maximum QRB setting.](/manual/en/configuration/#default-maximum-qrb)
+
+[Read how the optional local DX Cluster output works.](/features/dx-cluster/)

website/src/features/dual-chat.md

@@ -15,6 +15,9 @@ tagsList:
   - SHF
   - microwave contest
 related:
+  - private-message-handling
+  - trx-qrg-synchronisation
+  - band-recognition
   - priority-score
   - log-sync
   - airscout
@@ -169,4 +172,4 @@ KST4Contest cannot determine whether two operators behind those logins are using
 
 [Read how Worked and band information is derived.](/manual/en/features/#worked-callsigns-new-bands-and-new-grid-squares)
 
-[Read how suffixed callsigns are handled in skeds.](/features/sked-reminder/)
+[Read how suffixed callsigns are handled in skeds.](/features/sked-reminder/)

website/src/features/dx-cluster.md

@@ -12,8 +12,13 @@ tagsList:
   - QRG detection
   - UCXLog
   - N1MM+
+  - Minos
   - contest logger
 related:
+  - global-message-views
+  - qrg-detection
+  - station-map
+  - directional-opportunities
   - log-sync
   - priority-score
   - dual-chat
@@ -226,6 +231,7 @@ The local DX Cluster interface has been used with:
 
 - UCXLog
 - N1MM+
+- Minos
 
 Other loggers may work if they can open a normal TCP connection to a DX Cluster server and accept conventional `DX de ...` spot lines.
 

website/src/features/global-message-views.md

@@ -0,0 +1,90 @@
+---
+title: Global Message Views
+icon: 📋
+category: ON4KST Chat
+since: "1.42"
+summary: Follow public chat, ON4KST DX cluster traffic and directed messages between other stations without tying the overview to the currently selected station.
+description: KST4Contest provides three global message views for current chat activity and coordination, backed by shared, bounded in-memory message stores.
+tagsList:
+  - ON4KST
+  - public messages
+  - DXCluster messages
+  - QSO of the other
+  - chat activity
+  - contest coordination
+related:
+  - private-message-handling
+  - qso-monitoring
+  - directional-opportunities
+  - dx-cluster
+  - qrg-detection
+---
+
+## Why use a global message view?
+
+Selecting a station is useful when the next action concerns that station. It is less useful when the operator needs to keep an eye on the wider chat while moving through the user list.
+
+KST4Contest therefore provides three message tabs whose contents do not depend on the currently selected station. They keep public activity, cluster traffic and visible coordination between other stations available as a compact contest overview.
+
+Global Message Views are included from version 1.42 onwards.
+
+![Global message tabs below the main user list](/manual/assets/global_message_tabs.png)
+
+## Three views, three purposes
+
+| View | What it shows |
+|---|---|
+| **Public messages** | Public chat messages, including CQ calls and beacons |
+| **DXCluster messages** | DX cluster messages received from the ON4KST server |
+| **QSO of the other** | Directed chat messages between two chat logins other than the local station |
+
+**Public messages** is selected by default. Changing the selected user-list row does not filter or replace the contents of any of these tabs.
+
+## Public messages
+
+The public view is the continuous chat channel: CQ calls, beacons and other messages addressed to `ALL`. It provides the quickest indication of general activity without requiring a particular station to be selected first.
+
+This makes it useful as a running contest work surface. The operator can follow new calls and general announcements while the selection remains on the station currently being handled.
+
+## DXCluster messages
+
+The cluster view displays DX cluster traffic delivered through the ON4KST connection. Depending on the received data, it can show the reporting and reported stations, their locators, QRG, message text and the global Worked state of the reported station.
+
+This is an incoming message view. It is not the [Local DX Cluster Server](/features/dx-cluster/), which sends derived KST4Contest spots to connected logging software.
+
+## QSO of the other
+
+This view contains directed chat messages for which neither sender nor receiver is the local station. Messages addressed to `ALL` remain in **Public messages** instead.
+
+Sender and receiver are shown separately, together with their most recently known QRGs, global Worked states, message text and chat category. That can reveal current sked arrangements, frequency exchanges and other coordination which would otherwise be distributed across the station-related views.
+
+The label is deliberately compact. A directed chat message does not prove that an actual radio QSO has taken place. It may be a sked request, a frequency question or simply a private conversation between two chat logins.
+
+Two other limits matter:
+
+- **Last QRG TX** and **Last QRG RX** show the latest values currently known for the stations. They are not a historical record of the frequencies used when the displayed message was sent.
+- **wkd TX?** and **wkd RX?** show global Worked state. They do not say that the station was worked on the QRG or band displayed next to it.
+
+## The separate monitor uses the same data
+
+The existing **Cluster & QSO of the other** window remains available. It places received DX cluster messages above the directed messages between other stations.
+
+![Separate monitor window for DX cluster traffic and directed messages between other stations](/manual/assets/cluster_qso_monitor.png)
+
+The main-window tabs and monitor window use the same underlying message stores. Opening the additional window does not create another ON4KST connection, receive a second copy of each message or maintain a separate history.
+
+## Shared, bounded and session-only
+
+**Public messages**, the private-message table, the messages in **Further Info** and **QSO of the other** are different views of the same global chat-message store. The cluster tab and the cluster table in the separate monitor likewise share one DX-cluster-message store.
+
+Both stores are bounded. The chat-message store is reduced from more than 30,000 entries to 25,000; the cluster-message store is reduced from more than 10,000 entries to 8,000. The oldest entries disappear from every view which uses the respective store.
+
+The stores exist in memory only. After restarting KST4Contest, the views start empty and are rebuilt from newly received messages. They are tools for the current operating session, not a permanent chat archive.
+
+In practical terms: Global Message Views keep the wider contest conversation visible while the operator continues working station by station. They show observed chat activity and coordination, not a logbook of what happened on the radio.
+
+[Read the detailed derivation and limitations in the manual.](/manual/en/features/#global-message-views)
+
+[Open the user-interface description of the tabs and monitor window.](/manual/en/user-interface/#global-message-tabs-and-monitor-window)
+
+[Read how the bounded message stores are shared.](/manual/en/features/#bounded-message-stores-from-v141)

website/src/features/log-sync.md

@@ -13,6 +13,9 @@ tagsList:
   - DXLog.net
   - contest logger
 related:
+  - trx-qrg-synchronisation
+  - station-filters
+  - band-recognition
   - priority-score
   - dual-chat
   - sked-reminder
@@ -56,4 +59,4 @@ Worked, NOT-QRV and worked-grid information is stored in the internal SQLite dat
 
 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/)
+[Read the complete log synchronisation setup in the manual.](/manual/en/log-sync/)

website/src/features/macros.md

@@ -13,6 +13,7 @@ tagsList:
   - ON4KST
   - operator workflow
 related:
+  - trx-qrg-synchronisation
   - airscout
   - dual-chat
   - sked-reminder
@@ -227,4 +228,4 @@ In plain terms: the variables remove repeated typing. The operator still checks
 
 [Open the shortcut and snippet configuration.](/manual/en/configuration/#shortcut-settings)
 
-[Read how the AirScout values are obtained.](/features/airscout/)
+[Read how the AirScout values are obtained.](/features/airscout/)

website/src/features/priority-score.md

@@ -15,6 +15,9 @@ tagsList:
   - SHF
   - contest workflow
 related:
+  - station-filters
+  - qrg-detection
+  - band-recognition
   - timeline
   - airscout
   - sked-reminder
@@ -345,4 +348,4 @@ In practical terms: the score keeps the available information from having to be
 
 [Read how active suffix variants remain separate message targets.](/features/dual-chat/)
 
-[Read how Priority Candidates are used on the timeline.](/features/timeline/)
+[Read how Priority Candidates are used on the timeline.](/features/timeline/)

website/src/features/private-message-handling.md

@@ -0,0 +1,94 @@
+---
+title: Private Message Handling
+icon: ✉️
+category: ON4KST Chat
+since: "1.1"
+summary: Catch mentions of the configured login callsign from public or directed chat traffic and use six green age levels without changing the original message routing.
+description: KST4Contest combines PM Catching, age-based row highlighting and reply preparation for direct messages and callsign mentions across the visible chat traffic.
+tagsList:
+  - ON4KST
+  - private messages
+  - PM Catching
+  - message age
+  - callsign mention
+  - contest workflow
+related:
+  - automatic-replies
+  - qso-monitoring
+  - global-message-views
+  - dual-chat
+---
+
+## Why catch more than direct PMs?
+
+Not every message which concerns the local station is addressed to it directly. An operator may accidentally post something like this publicly:
+
+```text
+(DM5M) pse ur qrg
+```
+
+The callsign may also appear in a directed message between two other chat participants. KST4Contest therefore also shows every message not sent by the local station in the PM table when its text contains the configured local login callsign. This covers public messages addressed to `ALL` and directed traffic between other stations.
+
+PM Catching has existed since version 1.1. For directed messages between other stations, a slightly flippant description is **“gossip detection”**. It is a nickname, not the formal name of the function.
+
+## How is a mention recognised?
+
+The check searches the message text for the complete configured login callsign without distinguishing upper- and lower-case letters. A login of `DM5M` therefore matches both:
+
+```text
+(DM5M) pse ur qrg
+dm5m are you qrv?
+```
+
+This is a text search, not a linguistic interpretation. A spelling error or shortened callsign does not match. Conversely, a sentence which merely mentions the callsign can appear in the PM table even when no reply was expected.
+
+In plain terms: PM Catching finds visible callsign text. It cannot know what the author meant.
+
+## The original message remains unchanged
+
+Catching adds the message to the PM view. It does not turn it into a private message to the local station. The actual receiver remains `ALL` or the other chat participant; message text, chat category and routing remain unchanged as well.
+
+The same principle applies to [QSO Monitoring](/features/qso-monitoring/): a monitored message may be shown additionally in the PM table, but its original routing remains intact. The two mechanisms use different criteria:
+
+- PM Catching looks for the local login callsign in the message text.
+- QSO Monitoring checks whether a configured station is actually the sender or receiver.
+
+## Selecting a row prepares the reply
+
+Selecting an incoming PM-table row prepares a `/cq` reply to its sender. If the selected row contains an outgoing message from the local station, KST4Contest instead restores the original receiver as the reply target.
+
+The selection prepares the target and input context. It does not send a message automatically.
+
+## Six green age levels
+
+Age-based row highlighting is included from version 1.25 onwards. New non-local rows in the PM table pass through six green stages:
+
+| Message age | Display |
+|---|---|
+| up to and including 30 seconds | first green level |
+| 31 to 60 seconds | second green level |
+| 61 to 90 seconds | third green level |
+| 91 to 120 seconds | fourth green level |
+| 121 to 180 seconds | fifth green level |
+| 181 to 300 seconds | sixth green level |
+| from 301 seconds | normal table colour |
+
+The table refreshes the age display every five seconds. A colour boundary may therefore become visible during the next refresh rather than at the exact second.
+
+After five minutes, the row returns to the normal table colour. Messages sent by the local station retain their separate highlight and do not use the green age scale.
+
+## What produces a PM notification sound?
+
+PM audio is reserved for messages actually directed to the local login. A message shown through PM Catching does not trigger the simple PM sound, CW callsign output or phonetic callsign output.
+
+Messages added through QSO Monitoring likewise remain silent. Their appearance in the PM table is a visual aid, not evidence that the local station received a new private message.
+
+In practical terms: the PM table brings the relevant lines together, the age colours show what is fresh, and selecting a row prepares the likely reply target. The operator still decides whether the message was really intended for the station and whether it needs an answer.
+
+[Read the PM Catching recognition and its limits in the manual.](/manual/en/features/#pm-catching-from-v11)
+
+[Read the exact six age levels.](/manual/en/features/#coloured-pm-rows-from-v125)
+
+[Open the PM-window controls and selection behaviour.](/manual/en/user-interface/#pm-window-top-left)
+
+[Read which incoming messages produce audio notifications.](/manual/en/configuration/#notification-settings)

website/src/features/qrg-detection.md

@@ -0,0 +1,104 @@
+---
+title: Automatic QRG Detection
+icon: 📻
+category: ON4KST Chat
+since: "1.1"
+summary: Recognise complete and relative QRG information in chat messages and retain the sender's recent band context before using a global fallback.
+description: KST4Contest extracts usable frequencies from public and directed ON4KST messages and makes the result available to band, priority, sked, path and logger workflows.
+tagsList:
+  - QRG detection
+  - frequency
+  - relative QRG
+  - band context
+  - ON4KST
+  - contest workflow
+related:
+  - global-message-views
+  - trx-qrg-synchronisation
+  - band-recognition
+  - station-map
+  - priority-score
+  - sked-reminder
+  - dx-cluster
+---
+
+## Why detect a frequency from chat text?
+
+Frequencies in the ON4KST chat are rarely written in one consistent form. One station may send `432.088`, then shorten the next message to `.100`. Another may write `qrg 210` while a bare `210` in a different message means something else entirely.
+
+KST4Contest evaluates both public and directed chat messages so that useful QRG information does not have to be copied manually into every later operating step.
+
+Automatic QRG Detection has existed since version 1.1. The more precise sender-specific context evaluation described below is included from version 1.42 onwards.
+
+## Which forms are recognised?
+
+Complete frequencies provide their band directly. Examples include:
+
+```text
+144.210
+432,088
+10368.100
+```
+
+Relative forms omit the band and need additional context:
+
+```text
+.210
+,088
+qrg 210
+freq is 210
+on 210
+210 MHz
+```
+
+A dot or comma marks a relative frequency explicitly. A three-digit value is accepted only when nearby text identifies it as a frequency.
+
+## Which band is used for a relative QRG?
+
+KST4Contest resolves the missing band in this order:
+
+1. It first looks for a suitable band context detected for the same sender during the previous 30 minutes.
+2. If several current bands are known, it uses the most recently updated plausible context.
+3. Only when no suitable station context exists does it use the configured **Fallback band for relative QRG detection**.
+
+For example, assume that the global fallback is 144 MHz. A station first sends `432.088` and then `.100` a few minutes later. The recent context belongs to the same sender, so the result is `432.100 MHz`, not `144.100 MHz`.
+
+Another station without suitable recent context would use the global fallback for the same `.100` message.
+
+## Why are bare three-digit numbers ignored?
+
+Values such as:
+
+```text
+210
+599
+144
+```
+
+are deliberately not treated as QRGs without recognisable frequency context. Otherwise, a signal report of `599`, a band name or a QSO count could become a formally valid but operationally useless frequency.
+
+Rejecting an ambiguous number is less convenient than guessing correctly. It is considerably more convenient than tuning to a frequency which existed only in the parser's imagination.
+
+## Where is the detected QRG used?
+
+The most recently detected frequency appears in the **QRG** column. The same information can also contribute to:
+
+- [Band Recognition](/features/band-recognition/) and open band opportunities;
+- the [Priority Score](/features/priority-score/);
+- frequency selection for [skeds](/features/sked-reminder/);
+- the selected frequency for [path analysis](/features/station-map/); and
+- automatic or manually triggered [DX Cluster spots](/features/dx-cluster/).
+
+If a QRG appears in the same message which creates a directional opportunity, it is processed before the optional spot check. The new frequency can therefore already be used for that spot.
+
+## Text evidence is not current operating proof
+
+The result is derived from message text. KST4Contest cannot prove that the sender is still operating on the detected frequency, that the value was not superseded outside the chat or that an apparently clear statement belongs to the intended operating context.
+
+A detected QRG is useful working information. It is not a live measurement and not a guarantee that calling on that frequency will reach the station.
+
+In practical terms: the function preserves frequency context which would otherwise be easy to lose. The operator still checks whether that context remains plausible before using it.
+
+[Read the complete QRG Detection description in the manual.](/manual/en/features/#qrg-detection)
+
+[Open the fallback-band configuration.](/manual/en/configuration/#fallback-band-for-relative-qrg-detection)

website/src/features/qso-monitoring.md

@@ -14,6 +14,8 @@ tagsList:
   - contest team
   - dual chat
 related:
+  - private-message-handling
+  - global-message-views
   - dual-chat
   - sked-reminder
   - automatic-replies
@@ -94,4 +96,4 @@ The list can be edited directly and is stored with **Save Settings**.
 
 [Read the complete QSO monitoring configuration in the manual.](/manual/en/configuration/#sniffer-settings-from-v131)
 
-[Read why complete callsigns and chat categories remain separate.](/features/dual-chat/)
+[Read why complete callsigns and chat categories remain separate.](/features/dual-chat/)

website/src/features/rotator-control.md

@@ -13,6 +13,8 @@ tagsList:
   - UDP
   - SPID
 related:
+  - station-map
+  - directional-opportunities
   - priority-score
   - timeline
   - airscout
@@ -74,4 +76,4 @@ In plain terms: KST4Contest removes the repeated transfer of a direction from on
 
 [Read the complete setup and port assignment in the manual.](/manual/en/configuration/#pstrotator-settings-from-v131-fully-configurable-from-v140)
 
-[Open the PSTRotator website.](https://www.pstrotator.com/)
+[Open the PSTRotator website.](https://www.pstrotator.com/)

website/src/features/sked-reminder.md

@@ -11,6 +11,8 @@ tagsList:
   - contest reminder
   - Win-Test
 related:
+  - trx-qrg-synchronisation
+  - qrg-detection
   - priority-score
   - airscout
   - timeline
@@ -69,4 +71,4 @@ The proposed band is derived from recent chat and station-name information. This
 
 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)
+[Read the complete sked handling and its limitations in the manual.](/manual/en/features/#skeds-and-sked-reminders)

website/src/features/station-filters.md

@@ -0,0 +1,103 @@
+---
+title: Combinable Station Filters
+icon: 🔎
+category: Contest Awareness
+since: "1.0"
+summary: Combine spatial, operating and propagation filters to focus the user list and station map without removing hidden stations from the active chat context.
+description: KST4Contest applies several station filters together while keeping the canonical station model, message processing and Priority List independent of the filtered table view.
+tagsList:
+  - station filters
+  - QTF
+  - QRB
+  - New bands
+  - AirScout
+  - Tropo
+  - Worked
+  - contest workflow
+related:
+  - station-map
+  - band-recognition
+  - priority-score
+  - airscout
+  - log-sync
+---
+
+## Why combine station filters?
+
+A busy ON4KST category can contain far more stations than are relevant to the current antenna direction, band or operating moment. One filter rarely describes the complete situation.
+
+KST4Contest therefore allows spatial, operating and propagation-related conditions to be active at the same time. The purpose is not to discard stations. It is to reduce the visible worklist to the contacts which currently deserve attention.
+
+![Station filters wrapped into two rows](/manual/assets/filter_bar_wrapped.png)
+
+## Three kinds of filter
+
+### Spatial filters
+
+- **Show only QTF** keeps stations inside the selected antenna direction and configured beamwidth.
+- **Show only QRB [km] <=** limits the list to the entered distance.
+
+### Operating filters
+
+- **Find** matches a complete or partial callsign.
+- **wkd** hides base callsigns already worked on at least one supported band.
+- The individual band buttons hide stations already worked or marked NOT QRV on that band.
+- **Inactive stations** removes stations whose latest chat activity is too old.
+- **Only new grids** retains stations in four-character grid squares not yet worked.
+- **New bands** retains stations with at least one known, locally enabled and unworked band opportunity.
+
+### Propagation-related filters
+
+- **Tropo >=0dB** uses the available path-assessment result.
+- **AS next 5m** retains stations with a current AirScout opportunity or one expected within the next five minutes.
+
+These groups describe the operator's question, not separate processing stages. Every active filter is applied to the same station view.
+
+## Active filters use AND logic
+
+Several enabled filters are combined with AND. A station remains visible only when it satisfies every active condition.
+
+For example, the operator can combine:
+
+1. a QTF sector;
+2. a maximum QRB;
+3. **New bands**; and
+4. **AS next 5m**.
+
+The result contains only stations which lie in the chosen direction and distance, still offer a common unworked band and have a suitable AirScout window within the next five minutes.
+
+This is deliberately strict. Adding another filter narrows the result; it does not add a second independent group of candidates.
+
+## User list and map share the result
+
+The user list and [Station Map](/features/station-map/) use the same filtered station set. If a station disappears from the table because of QTF, QRB, Worked, band or propagation criteria, it also disappears from the geographical view.
+
+This makes the map useful as a spatial worklist rather than a second list with different rules.
+
+## Hidden does not mean deleted
+
+A filtered-out station remains in the active station model and continues to participate in chat processing. Incoming messages, QRG and band updates, Worked changes and other state can therefore make it relevant again.
+
+The [Priority List](/features/priority-score/) is intentionally independent of the table filters. A high-priority candidate may still appear there while its row is hidden in the user list. Selecting that candidate updates the current station and **Further Info**, but does not silently disable the active filters.
+
+## `Grid color` and `Reachability` are not filters
+
+**Grid color** changes only the appearance of the QRA cell for an already worked four-character grid square. It does not remove a station and remains enabled when **Reset filters** is used.
+
+The **Reachability** selector determines the band used for the Tropo column, the Tropo filter and an explicitly requested path calculation. Selecting a band does not itself filter the list. The choice is therefore also retained by **Reset filters**.
+
+## Unknown Tropo results remain visible
+
+**Tropo >=0dB** removes only stations for which a completed calculation returned a negative SSB margin.
+
+Stations with a pending, missing or failed result remain visible. Missing data is not evidence that a path is unsuitable. Treating every absent online result as a negative path assessment would make the filter look decisive while merely hiding uncertainty.
+
+## Filters react to new information
+
+The visible result changes when relevant station data changes. A new log entry can remove a station through the Worked filter. A detected QRG may create a [Band Recognition](/features/band-recognition/) result for **New bands**. New [AirScout](/features/airscout/) information can make a station pass **AS next 5m**.
+
+In practical terms: the filter bar turns the current station model into a temporary operating view. It does not create a smaller, disconnected copy of the contest.
+
+[Read the complete filter and Reachability controls in the manual.](/manual/en/user-interface/#filters-and-reachability-controls)
+
+[Read how Worked and band information changes through log synchronisation.](/features/log-sync/)

website/src/features/station-map.md

@@ -0,0 +1,99 @@
+---
+title: Station Map and Path Analysis
+icon: 🗺️
+category: Contest Awareness
+since: "1.41"
+summary: Use the filtered chat-member list as a geographical contest worklist and examine the selected radio path with terrain, Fresnel and link-budget estimates.
+description: KST4Contest projects the current filtered station context onto a map and provides an engineering estimate of the selected path.
+tagsList:
+  - station map
+  - path analysis
+  - terrain profile
+  - Fresnel zone
+  - link budget
+  - Open-Meteo
+  - Copernicus GLO-90
+  - contest workflow
+related:
+  - station-filters
+  - qrg-detection
+  - band-recognition
+  - directional-opportunities
+  - dx-cluster
+  - rotator-control
+---
+
+## Why use a map during a contest?
+
+A table is efficient when callsigns, scores or QRBs need to be sorted. It is less immediate when the operator wants to see which unworked stations remain in one direction or how they relate to the current antenna sector.
+
+Since version 1.41, the KST4Contest station map provides this geographical view of the same operating context. It is not an independent list. The filters applied to the chat-member table also determine which stations appear on the map.
+
+![Station map with path analysis](/manual/assets/station_map_path_analysis.png)
+
+## A geographical contest worklist
+
+With the **wkd** filter enabled, worked callsigns disappear from the user list. They also disappear from the map. What remains is a spatial worklist of stations which may still be relevant to the contest.
+
+The map retains the context already known by KST4Contest:
+
+- normal, Worked, directional-opportunity and selected marker states;
+- known bands and open `B+` opportunities;
+- the configured antenna direction, beamwidth and maximum QRB as a visible sector; and
+- a Maidenhead locator grid for geographical orientation.
+
+Only stations with a usable six-character locator can be positioned. Active chat variants of the same normalised base callsign are combined into one marker, while their actual message destinations remain separate.
+
+Green has a specific meaning: it marks a directional opportunity derived from directed ON4KST messages. It does not merely mean that the marker happens to lie inside the local antenna sector.
+
+## Selection remains connected to the chat
+
+Selecting a marker selects the corresponding active chat member in the main window. KST4Contest scrolls to the entry in the user list, updates **Further Info** and prepares the complete visible callsign as the message target.
+
+The suffix and chat category are retained. Combining several active variants into one geographical marker therefore does not turn them into one interchangeable ON4KST login.
+
+The selected path is shown as a connection line. The map can then remain a quick selection surface or be used together with the lower path-analysis panel.
+
+## G1YBB's map-driven workflow
+
+G1YBB uses the map particularly consistently as a geographical contest worklist:
+
+1. Enable the Worked filter so that already worked stations are removed.
+2. Select an interesting station on the map.
+3. Use **Trigger cluster spot** to send its known QRG to the connected logger.
+4. Select the spot in Minos and move the radio to that QRG.
+5. Complete and log the QSO.
+6. Log synchronisation updates the Worked state, and the filter removes the station from both the user list and the map.
+
+This creates a direct visual progression through the remaining stations. It is an optional and deliberately consistent operating method, not a prerequisite for using the map or KST4Contest.
+
+[Watch G1YBB demonstrate this workflow.](https://www.youtube.com/watch?v=BCNCjowPgec)
+
+## What does the path analysis calculate?
+
+For the selected station, KST4Contest currently requests terrain elevations from the Open-Meteo elevation service. The provider uses Copernicus GLO-90 data, and one path is sampled with no more than 100 evenly distributed elevation points.
+
+The resulting profile combines information including:
+
+- terrain and the geometrical line between both antennas;
+- radio and terrain horizons;
+- the first Fresnel zone and its minimum clearance;
+- possible Fresnel-zone intrusion and a rough diffraction estimate;
+- a frequency selected from current QRG or band context; and
+- an estimated link budget using power, antenna gain, feeder loss and path loss.
+
+The **Frequency** shown in the panel is the value actually used for the calculation. It should be checked before interpreting the Fresnel zone or link budget, especially on the microwave bands.
+
+## Engineering estimates, not measured conditions
+
+The nominal resolution of the terrain model is not the distance between requested points. On a long path, 100 samples can leave substantial gaps, and narrow obstacles may remain undetected.
+
+The calculation also cannot know the exact remote antenna height and pattern, buildings, vegetation, current atmospheric refractivity, interference or whether a detected QRG is still in use. Line of sight, Fresnel clearance, horizons and the link budget therefore remain technical estimates.
+
+In practical terms: the map keeps the remaining contest stations geographically visible, while the path analysis exposes useful assumptions about one selected route. Neither view predicts propagation or guarantees a QSO.
+
+[Read the complete map and path-analysis description in the manual.](/manual/en/features/#station-map-and-path-analysis-from-v141)
+
+[Open the map controls in the user-interface manual.](/manual/en/user-interface/#station-map)
+
+[Open the path-analysis and link-budget settings.](/manual/en/configuration/#path-analysis-and-link-budget)

website/src/features/trx-qrg-synchronisation.md

@@ -0,0 +1,90 @@
+---
+title: TRX/QRG Synchronisation
+icon: 🎛️
+category: Station Control
+since: "1.0"
+summary: Keep the primary operating frequency in MYQRG current from RadioInfo or Win-Test STATUS packets while leaving logging and SECONDQRG independent.
+description: KST4Contest can take the local primary QRG from compatible logger packets and make it available immediately to messages, beacons, QRG replies and Win-Test sked handover.
+tagsList:
+  - TRX synchronisation
+  - QRG
+  - MYQRG
+  - RadioInfo
+  - Win-Test
+  - contest logger
+related:
+  - log-sync
+  - macros
+  - automatic-replies
+  - dual-chat
+  - sked-reminder
+  - qrg-detection
+---
+
+## Why synchronise the local QRG?
+
+Changing frequency in the logger and then copying the same value into the chat client is easy to forget. The result may be a perfectly valid beacon or QRG reply which points to yesterday's frequency.
+
+KST4Contest can therefore update the primary local QRG, `MYQRG`, from the logger. The current value is then available immediately wherever the application's own QRG is required.
+
+TRX/QRG Synchronisation has existed since version 1.0. Support for native Win-Test `STATUS` packets is included from version 1.31 onwards.
+
+![TRX/QRG synchronisation settings](/manual/assets/client_settings_window_trxsync.png)
+
+## Which sources can update MYQRG?
+
+Two automatic sources are available:
+
+- compatible `RadioInfo` packets received through the shared log-sync UDP listener; and
+- native Win-Test `STATUS` packets received through the Win-Test network listener.
+
+If neither source is enabled, `MYQRG` can be entered manually in the main window. Enabling an automatic source makes the received value the primary QRG instead.
+
+## Frequency and QSO synchronisation are separate
+
+The general UDP listener may receive QSO data and `RadioInfo` packets on the same port, but KST4Contest treats them as different functions.
+
+A `RadioInfo` packet can update `MYQRG`; it does not mark a station as worked. Conversely, QSO or Worked synchronisation updates the log-derived station state without automatically changing the local QRG.
+
+This separation is deliberate. A radio frequency says where the local station is operating. It says nothing about which remote station has just been worked.
+
+## MYQRG does not mean SECONDQRG
+
+Both automatic sources update `MYQRG` only. This is the local QRG of the first or primary chat category.
+
+`SECONDQRG` remains independent and is not derived from incoming TRX packets. A dual-chat setup can therefore follow the logger automatically for the primary category while retaining a separately entered QRG for the second category.
+
+## Main or pass frequency from Win-Test
+
+By default, KST4Contest uses the main frequency from a Win-Test `STATUS` packet. It can instead be configured to use the pass frequency.
+
+If the pass value is missing or invalid, KST4Contest falls back to the main frequency. An unusable pass value therefore does not clear `MYQRG` or replace it with an invalid frequency.
+
+Several Win-Test operating positions may transmit `STATUS` packets on the same network. The configured station-name filter accepts QRG updates only from the intended position. This prevents another operating position from taking over the local frequency merely because its packet arrived later.
+
+## What happens with several frequency sources?
+
+All enabled sources write to the same `MYQRG` value. KST4Contest does not assign a fixed priority to `RadioInfo` and Win-Test `STATUS` packets.
+
+If several sources are active, the most recently processed packet determines the current primary QRG. That is useful when the sources describe the same radio. Independent radios should not compete for the same value unless that last-packet behaviour is actually intended.
+
+## Where is the synchronised QRG used?
+
+The current primary QRG is immediately available for:
+
+- [macros and variables](/features/macros/), including `MYQRG` and `MYQRGSHORT`;
+- automatic beacons;
+- [automatic QRG replies](/features/automatic-replies/) in the primary chat category; and
+- a matching primary local-frequency fallback when a [sked is handed to Win-Test](/features/sked-reminder/).
+
+The sked handover still checks whether the local QRG belongs to the selected band. Synchronisation supplies the value; it does not bypass that validation.
+
+## What the function does not do
+
+TRX/QRG Synchronisation tracks the local station's primary frequency. It does not detect the QRG of a remote station from chat text; that is the separate [Automatic QRG Detection](/features/qrg-detection/) function.
+
+It also does not turn a `RadioInfo` packet into a logged QSO. Worked information remains the responsibility of [Log Synchronisation](/features/log-sync/).
+
+In practical terms: one current local QRG can feed several operating workflows, but it remains one value. `SECONDQRG`, remote-station frequencies and Worked state keep their own meanings.
+
+[Read the complete TRX Sync configuration in the manual.](/manual/en/configuration/#trx-sync-settings)