website: added direction opportunities to the features and added neccessary picture

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 |

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 |

website/src/features/band-recognition.md

@@ -14,6 +14,7 @@ tagsList:
   - ON4KST
   - contest workflow
 related:
+  - directional-opportunities
   - priority-score
   - dual-chat
   - log-sync
@@ -47,7 +48,7 @@ Recognition alone is not enough. KST4Contest compares the detected bands with:
 
 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.
 
-![Per-band NOT-QRV controls for the selected station](/manual/assets/not_qrv_controls.png)
+![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.
 

website/src/features/directional-opportunities.md

@@ -0,0 +1,74 @@
+---
+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:
+  - 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/dx-cluster.md

@@ -14,6 +14,7 @@ tagsList:
   - N1MM+
   - contest logger
 related:
+  - directional-opportunities
   - log-sync
   - priority-score
   - dual-chat

website/src/features/rotator-control.md

@@ -13,6 +13,7 @@ tagsList:
   - UDP
   - SPID
 related:
+  - directional-opportunities
   - priority-score
   - timeline
   - airscout
@@ -74,4 +75,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/)