manual: updated pstrotator settings descriptin. Source: implemented plausibility checks for pstrotator port range and changed ui blocking problem on the spid workaround

2026-08-24 02:57:43 +02:00 · 2026-08-16 03:05:46 +02:00
parent 422e6cf4b7
commit 8fa5360752
12 changed files with 845 additions and 97 deletions
@@ -0,0 +1,97 @@
+---
+title: Automatic Private Replies
+icon: ↩️
+category: ON4KST Chat
+since: "1.25"
+summary: Answer repeated private messages or QRG requests without losing the complete callsign, chat category or protection against automatic reply loops.
+description: KST4Contest can send a predefined answer to incoming private messages and provide the QRG belonging to the category in which a request was received.
+tagsList:
+  - ON4KST
+  - automatic reply
+  - private message
+  - QRG
+  - sked request
+  - dual chat
+related:
+  - dual-chat
+  - macros
+  - sked-reminder
+---
+
+## Why use an automatic reply?
+
+Not every station visible in the ON4KST chat is taking part in the current contest. Some operators may be monitoring activity, testing their station or simply remaining logged in while not accepting skeds.
+
+That distinction is not always checked before requests are sent. During a busy contest, the same station may therefore receive several similar private messages and have to enter the same refusal repeatedly.
+
+KST4Contest can provide that answer automatically while leaving the incoming message visible.
+
+## Two separate reply functions
+
+The general automatic reply sends one configured text in response to an incoming private message. A practical example is:
+
+```text
+Sri, I am not taking part in this contest. No skeds.
+```
+
+The QRG reply serves a different purpose. It recognises common questions such as:
+
+```text
+qrg?
+freq?
+pse qrg
+```
+
+and answers with the QRG belonging to the chat category in which the request was received:
+
+```text
+[KST4C Automsg] QRG is: 144.300.00
+```
+
+When both functions are enabled, a recognised QRG request receives the QRG reply only. It does not additionally trigger the general answer.
+
+## Category and callsign remain part of the message
+
+An automatic reply is addressed to the complete callsign of the sender, including any visible suffix. It is also sent through the same chat category as the incoming message.
+
+A request from `CALLSIGN-70` is therefore not silently redirected to `CALLSIGN`, and a message received through the microwave chat is not answered through the primary VHF/UHF category.
+
+This is particularly important in station setups which use separate suffixes for different bands or operating positions.
+
+## Missing information is not useful information
+
+KST4Contest sends a QRG reply only when a QRG is available for the relevant category. It does not produce an answer containing only:
+
+```text
+QRG is:
+```
+
+A general answer must likewise contain actual text and must not contain characters which would break the ON4KST protocol frame.
+
+Rejecting these replies locally is intentional. An automatic response which contains no usable information has saved nobody any work.
+
+## Preventing loops and repeated answers
+
+Every automatic reply contains:
+
+```text
+[KST4C Automsg]
+```
+
+Messages which already contain this prefix are not answered automatically. Two KST4Contest clients therefore do not continue replying to each other.
+
+A shared two-minute cooldown additionally applies to the general and QRG-specific functions. It is tracked separately for each complete callsign and chat category.
+
+A rejected reply does not start the cooldown. If a QRG was missing and is entered afterwards, the next request can be answered immediately.
+
+## Operational limits
+
+The function reacts to incoming text. It does not decide whether the sender's request was reasonable, whether a sked could be possible later or whether the configured refusal still reflects the current operating status.
+
+The general reply should therefore be enabled only while its text remains correct. A message which says that the station is not participating becomes misleading if the operator starts working the contest half an hour later.
+
+In plain terms: automatic replies remove repetitive typing. They do not take over the conversation.
+
+[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/)
@@ -0,0 +1,77 @@
+---
+title: PSTRotator Control
+icon: 🧭
+category: Station Control
+since: "1.31"
+summary: Point the antenna at a selected chat station and use the azimuth reported by PSTRotator throughout the KST4Contest operating context.
+description: KST4Contest calculates the direction of a selected station, sends it to PSTRotator and uses the reported antenna position for filters, priorities, timelines and map displays.
+tagsList:
+  - PSTRotator
+  - antenna rotator
+  - azimuth
+  - QTF
+  - UDP
+  - SPID
+related:
+  - priority-score
+  - timeline
+  - airscout
+---
+
+## Why connect the rotator to the chat client?
+
+A station selected in the chat already has a locator and a calculated QTF. Entering the same direction manually into another application adds another small task at precisely the point where the operator is preparing a contact.
+
+KST4Contest can send that direction directly to PSTRotator.
+
+![PSTRotator control for the selected station](/manual/assets/pstrotator_turn_antenna.png)
+
+## Sending a direction
+
+Press **Turn ant1 to …** in the Further Info section of the selected station.
+
+KST4Contest:
+
+1. calculates the azimuth from both station locators;
+2. disables PSTRotator tracking mode;
+3. sends the target as an integer azimuth; and
+4. receives the current position reported by PSTRotator.
+
+The function uses UDP. PSTRotator receives commands on the configured control port and reports its position on the following port.
+
+With the default control port `12000`, KST4Contest therefore listens on `12001`.
+
+## One position, several consumers
+
+The reported azimuth becomes the current QTF in KST4Contest. The value is subsequently used by:
+
+- the direction filter;
+- direction-opportunity detection;
+- the Priority Score;
+- the antenna sector on the map;
+- the AP and sked timeline; and
+- the `MYQTF` message variable.
+
+This shared use is intentional. The antenna should not be shown pointing in one direction while the filters and candidate calculations continue to assume another.
+
+## SPID compatibility check
+
+Some SPID configurations occasionally fail to react to the first direction command.
+
+KST4Contest checks the reported position after two seconds. If no movement was reported and the target has not been reached, it sends one compatibility sequence through `0°` and then repeats the intended target.
+
+The check runs in the background and does not block the user interface.
+
+## Limits of the integration
+
+The current interface controls and evaluates azimuth only. It does not provide elevation tracking.
+
+The reported QTF describes what PSTRotator returns. Whether the antenna mechanically reaches that exact position still depends on the rotor, controller, calibration and configured offsets.
+
+UDP also provides no delivery confirmation. Correct host, port, return port and firewall settings remain necessary.
+
+In plain terms: KST4Contest removes the repeated transfer of a direction from one window to another. It does not turn an uncalibrated rotor into a calibrated one.
+
+[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/)