website features and airscout information updated

website/src/_layouts/feature.njk

@@ -1,40 +1,44 @@
 ---
 layout: base.njk
+lang: en
 ---
 
 <section class="hero">
-  <p class="badge">{{ category }} · since {{ since }}</p>
+  <p class="eyebrow">{{ category }} · available since {{ since }}</p>
   <h1>{{ title }}</h1>
   <p class="lead">{{ summary }}</p>
+
+  <div class="actions">
+    <a class="button secondary" href="/features/">← All functions</a>
+    <a class="button ghost" href="/manual/en/">Open the manual</a>
+  </div>
 </section>
 
 <section class="section narrow">
   <article class="card content-card">
-    <div class="feature-icon large">{{ icon }}</div>
+    <div class="feature-icon large" aria-hidden="true">{{ icon }}</div>
 
     {{ content | safe }}
 
-    {% if tagsList %}
-      <h2>Keywords</h2>
-      <div class="tag-list">
-        {% for tag in tagsList %}
-          <span>{{ tag }}</span>
-        {% endfor %}
-      </div>
-    {% endif %}
-
     {% if related %}
-      <h2>Related features</h2>
+      <h2>Related functions</h2>
+
       <div class="actions">
         {% for slug in related %}
           {% for item in collections.sortedFeatures %}
             {% if item.fileSlug == slug %}
-              <a class="button secondary" href="{{ item.url }}">{{ item.data.title }}</a>
+              <a class="button secondary" href="{{ item.url }}">
+                {{ item.data.title }}
+              </a>
             {% endif %}
           {% endfor %}
         {% endfor %}
       </div>
     {% endif %}
+
+    <p>
+      <a href="/features/">← Back to all functions</a>
+    </p>
   </article>
 </section>
 
@@ -44,15 +48,29 @@ layout: base.njk
   "@type": "TechArticle",
   "headline": "{{ title }}",
   "description": "{{ summary }}",
-  "about": "KST4Contest",
+  {% if tagsList %}
-  "url": "https://kst4contest.hamradioonline.de{{ page.url }}",
+  "keywords": "{{ tagsList | join(', ') }}",
-  "author": {
+  {% endif %}
-    "@type": "Person",
+  "about": {
-    "name": "Praktimarc"
+    "@type": "SoftwareApplication",
+    "name": "KST4Contest",
+    "url": "https://kst4contest.hamradioonline.de/"
   },
+  "url": "https://kst4contest.hamradioonline.de{{ page.url }}",
+  "author": [
+    {
+      "@type": "Person",
+      "name": "Marc Fröhlich (DO5AMF)"
+    },
+    {
+      "@type": "Person",
+      "name": "Philipp (DN9APW)"
+    }
+  ],
   "publisher": {
     "@type": "Organization",
-    "name": "KST4Contest"
+    "name": "KST4Contest Project",
+    "url": "https://kst4contest.hamradioonline.de/"
   }
 }
 </script>

website/src/features/airscout.md

@@ -3,25 +3,173 @@ title: AirScout Integration
 icon: ✈️
 category: Aircraft Scatter
 since: "1.26"
-summary: Use AirScout AP predictions in candidate evaluation, the timeline and sked planning.
+summary: Request station-specific aircraft-scatter information from AirScout and include the returned AP timing in the user list, timeline and candidate priority.
-description: KST4Contest receives aircraft scatter information from AirScout and relates AP timing to active ON4KST stations.
+description: KST4Contest sends active station paths to AirScout, receives matching aircraft information and relates the result to the current ON4KST operating context.
 tagsList:
   - AirScout
   - airplane scatter
   - aircraft scatter
-  - VHF contest
+  - AP windows
+  - VHF
+  - UHF
+  - SHF
+  - contest
 related:
   - timeline
   - priority-score
   - sked-reminder
 ---
 
-## Airplane scatter in the operator workflow
+## Why connect AirScout to the chat client?
 
-Aircraft reflections can create short but valuable contact opportunities.
+An aircraft-scatter opportunity is useful for a limited time. AirScout can calculate the path and identify suitable aircraft, but it does not know which of the many stations in the ON4KST chat currently matters to the operator.
 
-KST4Contest helps combine ON4KST chat activity with AirScout-based propagation awareness.
+KST4Contest provides this missing context. It sends relevant active stations to AirScout and assigns the returned aircraft information to the corresponding chat members.
 
-## From candidate to sked decision
+The responsibilities remain separate:
 
-AirScout information can support the decision whether a candidate station should be called immediately, scheduled later or monitored for a better window.
+- AirScout obtains the aircraft data and evaluates the reflection geometry.
+- KST4Contest selects the station paths to request.
+- KST4Contest relates the returned timing to messages, candidate priorities and skeds.
+
+KST4Contest does not download ADS-B data and does not calculate the aircraft geometry itself.
+
+## Which stations are sent to AirScout?
+
+KST4Contest updates the AirScout requests every 60 seconds. A station is included only if:
+
+- AirScout communication is enabled;
+- the station has a usable callsign and locator;
+- its distance is known;
+- its QRB is below the configured maximum QRB; and
+- a usable propagation band can be determined.
+
+Active chat variants of the same base callsign are combined for the frequency decision. The path itself is requested once instead of sending duplicate calculations for every visible suffix or chat-category entry.
+
+KST4Contest also updates the AirScout watchlist. Stations which are no longer active or no longer meet the conditions are therefore not intended to remain permanent watchlist targets.
+
+## How is the AirScout band selected?
+
+> Automatic station-specific band selection is included in Nightly / v1.42. A fixed configured AirScout band remains available as a manual fallback.
+
+In **Auto per station** mode, KST4Contest uses the same propagation-frequency resolver as the internal path analysis. The sources are evaluated in the following order:
+
+1. the most recently detected QRG of the station;
+2. a band explicitly stated in the name of one of its active chat entries;
+3. 432 MHz when the station is present in both the VHF/UHF and microwave categories and 432 MHz is enabled locally;
+4. the lowest locally enabled fallback band belonging to the supported chat category.
+
+Only bands enabled for the local station are eligible. A manual NOT-QRV mark removes the corresponding band before the selection is made.
+
+Recent detected frequencies are preferred because the path should normally be evaluated for the band on which the contact is actually intended. A category alone is weaker evidence: it describes a range of possible activity, not necessarily the current operating band of one station.
+
+Unsupported ON4KST categories are ignored. They must not silently turn into a 144 MHz request merely because no better information is available.
+
+If no usable result remains, KST4Contest omits the AirScout request for that station.
+
+## What does AirScout return?
+
+AirScout replies with the aircraft currently considered relevant for the requested path. For each aircraft, KST4Contest receives information including:
+
+- the aircraft identifier;
+- the AirScout size category;
+- the distance to the expected reflection point;
+- the potential reported by AirScout; and
+- the remaining time until the expected arrival.
+
+The aircraft are ordered by their reported potential and, where this is equal, by arrival time.
+
+The result is assigned to every active chat variant of the corresponding base callsign. A station logged in as `CALLSIGN`, `CALLSIGN-2` or `CALLSIGN-432` therefore receives the same path information without merging the individual message targets.
+
+![AirScout information in the station overview](/manual/assets/priority_score_overview.png)
+
+## How does the result affect KST4Contest?
+
+AirScout information is used in several places:
+
+- The **AP** column shows the next available aircraft for a station.
+- The **Further Info** section provides the aircraft information for the selected station.
+- AP candidates can appear on the 30-minute timeline.
+- A station with available aircraft receives an additional Priority Score contribution.
+- An aircraft expected within the next few minutes raises the score further.
+- The `FIRSTAP` and `SECONDAP` variables can insert the information into a message.
+
+The percentage reported by AirScout is not interpreted as a contact probability. In particular, a displayed value of 100% does not mean that a QSO will succeed.
+
+![AirScout candidates and skeds on the timeline](/manual/assets/sked_timeline.png)
+
+## Priority and timing are separate questions
+
+The Priority Score currently considers whether AirScout has reported usable aircraft and how soon the earliest aircraft is expected. The detailed potential value is used for the AP display and the timeline colour, but it is not converted directly into a percentage-based score.
+
+This distinction is intentional. The AirScout value describes the aircraft geometry known to AirScout. The complete contest decision also depends on the band, antenna direction, activity of the remote station, Worked state and any existing sked.
+
+In plain terms: an aircraft may make the path interesting. It does not make the remote station ready.
+
+## Show the selected path in AirScout
+
+The direction button of the selected station can send an `ASSHOWPATH` request to AirScout. AirScout then opens or updates the corresponding path display.
+
+The request uses:
+
+- the configured AirScout server identifier;
+- the configured KST4Contest client identifier;
+- the selected propagation frequency;
+- the local callsign and locator; and
+- the complete callsign and locator of the selected station.
+
+The local ON4KST suffix is removed before the path request because AirScout expects the actual station callsign rather than a chat-specific login suffix.
+
+If the selected station has no usable locator or no propagation frequency can be determined, the request is omitted. Opening an impressive empty AirScout window would not add much information.
+
+## Several clients in the same network
+
+The default identifiers are:
+
+| Setting | Default |
+|---|---|
+| AirScout server identifier | `AS` |
+| KST4Contest client identifier | `KST` |
+| UDP port | `9872` |
+
+The server and client identifiers are configurable. This matters when several KST4Contest or AirScout instances are operated in the same station network.
+
+Each KST4Contest instance should use a distinct client identifier. Incoming AirScout replies are accepted only when the server and client identifiers exactly match the configured values. The comparison is case-sensitive.
+
+This keeps a reply for one operating position from being assigned to another client merely because both listen on the same UDP network.
+
+> Strict reply filtering by the configured client/server pair is included in Nightly / v1.42.
+
+## AP variables in messages
+
+The selected station can be referenced through two message variables:
+
+| Variable | Result |
+|---|---|
+| `FIRSTAP` | Description and arrival time of the first aircraft |
+| `SECONDAP` | Description and arrival time of the second aircraft |
+
+If no aircraft is available, `FIRSTAP` returns `no ap available`. If no second aircraft exists, `SECONDAP` is replaced with an empty string.
+
+The absence of a second aircraft is a normal result and does not prevent editing or sending the message.
+
+## What the integration cannot guarantee
+
+The result depends on several external and derived inputs:
+
+- the aircraft data available to AirScout;
+- the AirScout configuration and calculation;
+- the locator assigned to the remote station;
+- the band or frequency selected by KST4Contest;
+- the age of detected QRG information; and
+- the actual operating situation at the remote station.
+
+A missing aircraft in KST4Contest does not prove that the path is unusable. It may also mean that AirScout returned no matching result, the station was outside the configured QRB range, the locator was missing or no suitable band could be derived.
+
+Conversely, a reported aircraft does not guarantee sufficient signal strength or a completed contact.
+
+[Read the complete AirScout setup in the manual.](/manual/en/airscout-integration/)
+
+[Read how the AP information affects the timeline.](/features/timeline/)
+
+[Open the AirScout project on GitHub.](https://github.com/dl2alf/AirScout)

website/src/features/dual-chat.md

@@ -3,23 +3,170 @@ title: Dual Chat Categories
 icon: 💬
 category: ON4KST Chat
 since: "1.26"
-summary: Log in to two ON4KST categories and handle both message streams in one station list and interface.
+summary: Monitor two ON4KST categories in one interface while preserving the complete callsign and category required for correct message routing.
-description: KST4Contest combines two ON4KST chat categories while retaining the category required for messages and station context.
+description: KST4Contest combines two ON4KST chat sessions, keeps individual logins separate and shares station-related Worked, band and priority information through the normalised base callsign.
 tagsList:
   - ON4KST
   - dual chat
+  - multi-channel login
+  - callsign suffix
+  - VHF
+  - UHF
+  - SHF
   - microwave contest
 related:
   - priority-score
   - log-sync
+  - airscout
 ---
 
-## Two categories, one workflow
+## Why use two chat categories?
 
-KST4Contest can operate with two ON4KST chat categories at once.
+VHF, UHF and microwave activity is not always concentrated in one ON4KST category. An operator may need to follow one category for the lower bands and another for microwave operation.
 
-This is useful when contest activity spans VHF/UHF and microwave operation.
+Opening two unrelated chat clients would show both message streams, but every comparison between them would remain manual. Worked status, band information, active stations and sked context would still be distributed across separate windows.
 
-## Less window switching
+KST4Contest therefore opens up to two ON4KST chat sessions and processes both in one operating context.
 
-The operator can keep more information visible without constantly changing tools.
+![Primary and secondary chat settings](/manual/assets/client_settings_window_station.png)
+
+## Two connections remain two connections
+
+The primary and secondary chat sessions retain their own:
+
+- ON4KST chat category;
+- login callsign;
+- public message stream;
+- destination category for outgoing messages; and
+- active login entries.
+
+The second session can use the same local callsign as the primary session or a separately configured callsign. A different login may be useful when the station uses category- or band-specific suffixes.
+
+Combining the display does not turn both sessions into one ON4KST connection. Messages must still be sent through the category in which the intended destination is active.
+
+## What identifies an active chat member?
+
+An active login is identified by:
+
+1. the complete visible callsign, including its suffix; and
+2. the ON4KST chat category.
+
+Both parts are required.
+
+Consider the following active entries:
+
+| Complete callsign | Chat category | Active entity |
+|---|---:|---|
+| `9A0BB-2` | 1 | separate |
+| `9A0BB-70` | 1 | separate |
+| `9A0BB-23` | 2 | separate |
+| `9A0BB-13` | 2 | separate |
+
+All four entries belong to the same base callsign, but they are four different chat logins. Joining, updating or leaving the chat affects only the corresponding complete callsign in the corresponding category.
+
+This is particularly important for `9A0BB-2` and `9A0BB-70`: because both use the same category, the category alone cannot distinguish them.
+
+> Correct separation of several suffix variants within the same category is included in Nightly / v1.42 and fixes [Issue #73](https://github.com/praktimarc/kst4contest/issues/73).
+
+## How are messages routed?
+
+When a row is selected, KST4Contest retains both the complete callsign and its category. A private message is addressed to that complete callsign and sent through the corresponding chat session.
+
+Selecting `9A0BB-70` in category 1 therefore creates a message for `9A0BB-70` in category 1. It is not silently reduced to `9A0BB`, and it is not sent through category 2 merely because another variant is active there.
+
+The same distinction is used for:
+
+- incoming private messages;
+- outgoing message echoes;
+- public messages addressed to the local station;
+- station selection from the user list;
+- sked reminder messages; and
+- leaving or updating an active chat entry.
+
+The different variants do not have to be able to send messages to each other. That is not the purpose of the function. They must remain correctly reachable by other stations and receive the messages addressed to their respective login.
+
+## What is shared through the base callsign?
+
+Some information describes the radio station rather than one temporary chat login. This information is aggregated through the normalised base callsign.
+
+For the examples above, the common base callsign is `9A0BB`.
+
+The shared station context includes:
+
+- global Worked status;
+- Worked status per band;
+- manually assigned NOT-QRV marks;
+- known band opportunities derived from the active variants;
+- the Priority Score; and
+- stored contest state in the internal database.
+
+A QSO with `9A0BB-70` therefore also marks the corresponding base callsign as worked for the other active suffix variants. It would be misleading to present `9A0BB-2` as a completely new station immediately afterwards.
+
+Per-band information is still retained. Working the station on 70 MHz does not mark it as worked on 23 cm. The common base callsign links the variants; the band remains a separate dimension.
+
+## Why are band hints combined?
+
+A station may use its visible login names to describe the available bands:
+
+- `9A0BB-2`
+- `9A0BB-70`
+- `9A0BB-23`
+- `9A0BB-13`
+
+KST4Contest can evaluate these active variants together when deriving possible bands. Recent QRG information and band designators in the name fields can contribute as well.
+
+This allows the user list, the `a` and `B+` indicators, the **New bands** filter and the automatic propagation-frequency selection to use information which may be distributed across the two chat categories.
+
+A manual NOT-QRV mark still takes precedence. An automatically detected suffix or name is evidence of possible activity, not permission to ignore an explicit correction.
+
+## Why is the Priority Score not duplicated?
+
+The Priority Score represents the operating priority of the station, not the number of chat logins it happens to use.
+
+KST4Contest therefore calculates the score for the normalised base callsign and projects it to the active variants. Several suffixes do not create several independent priority candidates merely by being logged in more than once.
+
+The individual rows remain selectable because the correct message destination still matters.
+
+In plain terms: one station should not occupy half the priority list, but the operator must still be able to contact the correct login.
+
+## Categories are context, not proof of a band
+
+A chat category describes the general operating area of that chat. It does not prove that every station in the category is currently QRV on every associated band.
+
+KST4Contest therefore uses stronger station-specific information where available:
+
+1. a recently detected QRG;
+2. an explicit band designator in the station name or suffix;
+3. the locally enabled bands;
+4. stored Worked and NOT-QRV information; and
+5. only then a supported category fallback where the function requires one.
+
+Categories unrelated to the supported VHF, UHF, microwave or EME workflows are ignored by propagation functions which cannot derive a meaningful result from them. They must not cause a fallback to an arbitrary band.
+
+## What remains separate?
+
+Sharing the station context does not merge everything associated with the base callsign.
+
+The following remain tied to the individual login or message:
+
+- complete message destination;
+- chat category;
+- public message stream;
+- visible callsign suffix;
+- join and leave state;
+- the specific row selected by the operator; and
+- message history associated with that login and category.
+
+This distinction is the basis of the dual-chat implementation: operational information may be shared where it describes the same radio station, while communication remains attached to the actual ON4KST login.
+
+## Practical limitations
+
+The shared base-callsign model assumes that suffix variants separated by `-` belong to the same underlying amateur-radio station. That is appropriate for common logins such as `-2`, `-70`, `-144` or `-432`.
+
+KST4Contest cannot determine whether two operators behind those logins are using one station, several independently operated stations or a distributed contest setup. Worked and band information is therefore shared at callsign level, while the operator remains responsible for selecting the correct chat destination.
+
+[Read how both chat categories are configured.](/manual/en/configuration/#login-and-chat-categories)
+
+[Read how Worked and band information is derived.](/manual/en/features/#worked-callsigns-new-bands-and-new-grid-squares)
+
+[Read how suffixed callsigns are handled in skeds.](/features/sked-reminder/)

website/src/features/index.njk

@@ -1,28 +1,119 @@
 ---
 layout: base.njk
-title: KST4Contest Features
+lang: en
-description: Contest-optimized ON4KST features for VHF, UHF and SHF operation.
+title: KST4Contest Functions
+description: Technical overview of the KST4Contest functions for ON4KST chat processing, candidate evaluation, sked planning, AirScout and logger integration.
 ---
 
 <section class="hero">
-  <p class="badge">Features</p>
+  <p class="eyebrow">Functions</p>
-  <h1>Contest tools, not just chat windows.</h1>
+  <h1>How KST4Contest supports the contest workflow</h1>
+
   <p class="lead">
-    KST4Contest combines ON4KST chat, candidate scoring, AirScout workflow,
+    KST4Contest combines ON4KST messages with station, band, Worked, sked,
-    sked handling, log synchronization and operator decision support.
+    AirScout and logger information. The individual functions use this shared
+    context instead of treating every message or interface as an isolated
+    event.
   </p>
+
+  <p>
+    Some information is received directly from another program. Other
+    information must be derived from chat messages, station names or the
+    current operating state. The distinction matters: a detected band or a
+    calculated priority is useful context, but not automatically a confirmed
+    fact.
+  </p>
+
+  <div class="actions">
+    <a class="button" href="/manual/en/features/">Read the technical description</a>
+    <a class="button secondary" href="/manual/en/configuration/">Open configuration</a>
+    <a class="button ghost" href="/download/">Download KST4Contest</a>
+  </div>
 </section>
 
 <section class="section">
+  <div class="section-heading">
+    <p class="eyebrow">Shared context</p>
+    <h2>Why the functions affect each other</h2>
+    <p>
+      A newly detected frequency can change the known bands of a station. This
+      can affect its Worked state, filters, priority, map path and a later sked
+      handover. The same principle applies to information received from a
+      logger or entered manually.
+    </p>
+  </div>
+
   <div class="grid">
-    {% for feature in collections.features %}
+    <article class="card">
+      <h3>Received information</h3>
+      <p>
+        ON4KST messages, logger packets, Win-Test network data and AirScout
+        responses provide information at different levels of detail. Missing
+        fields are not automatically equivalent to negative information.
+      </p>
+    </article>
+
+    <article class="card">
+      <h3>Derived information</h3>
+      <p>
+        Bands, frequencies, activity and candidate priorities may be derived
+        from several sources. Explicit NOT-QRV information overrules a merely
+        inferred band opportunity.
+      </p>
+    </article>
+
+    <article class="card">
+      <h3>Operator decision</h3>
+      <p>
+        Scores, filters, AP windows and path assessments reduce the amount of
+        information that must be evaluated manually. They do not guarantee a
+        contact or replace checking the actual operating situation.
+      </p>
+    </article>
+  </div>
+</section>
+
+<section class="section">
+  <div class="section-heading">
+    <p class="eyebrow">Function overview</p>
+    <h2>Functions in their intended order</h2>
+    <p>
+      The pages below explain the operating problem behind each function, the
+      information it uses and the limitations that remain.
+    </p>
+  </div>
+
+  <div class="grid">
+    {% for feature in collections.sortedFeatures %}
       <article class="card feature-card">
         <div class="feature-icon">{{ feature.data.icon }}</div>
         <p class="eyebrow">{{ feature.data.category }}</p>
-        <h3><a href="{{ feature.url }}">{{ feature.data.title }}</a></h3>
+        <h3>
+          <a href="{{ feature.url }}">{{ feature.data.title }}</a>
+        </h3>
         <p>{{ feature.data.summary }}</p>
-        <a href="{{ feature.url }}">Learn more →</a>
+        <a href="{{ feature.url }}">Read how it works →</a>
       </article>
     {% endfor %}
   </div>
 </section>
+
+<section class="section">
+  <div class="cta-panel">
+    <p class="eyebrow">Technical details</p>
+    <h2>The manual remains the authoritative description</h2>
+
+    <p>
+      These pages provide a practical overview. Configuration parameters,
+      interface requirements, exact behaviour and version-specific limitations
+      are documented in the manual. Where the short description and the manual
+      differ, the manual should be corrected first. Two competing descriptions
+      of the same function would not improve matters.
+    </p>
+
+    <div class="actions">
+      <a class="button" href="/manual/en/">Open the English manual</a>
+      <a class="button secondary" href="/manual/de/">Deutsches Handbuch</a>
+    </div>
+  </div>
+</section>